Re: Timers in application (again)

Re: Timers in application (again)

[Robert I. Eachus]

Simon Wright wrote:
 
> Looking at the Linux code (kernel/sched.c, function sys_nanosleep())
> it is very hard to see how the effect you describe could possibly be
> achieved, except perhaps with a busy wait -- indeed, Linux does just
> that for RT nanosleeps of <= 2mS, a behaviour I don't think we want to
> retain!

   One of the nicest features of Linux is that you can substitute a
working
clock, assuming that the hardware has one you can get to, and you are
all set.
One nice thing about the Amiga is that you get an interrupt at the
beginning of
every scan line on the display.  But even this only allowed hard
scheduling on a
granularity of tens of microseconds.  Outside of Amigas, most modern
hardware
will give you a clock interrupt about every millisecond at best.  (One
1024th of
a second is pretty common.)

Re: Timers in application (again)

[Robert I. Eachus]

Simon Wright wrote:
> 
> "Robert I. Eachus" <rieachus@earthlink.net> writes:
...
> >    Assuming Ada.Real_Time.Time_Span is greater than the time required to
> > execute the loop,
> > and that any higher priority tasks don't eat up too much wall clock
> > time, Action should take place at intervals of one tick, not two.  This
> > is one of the reasons that delay until was added to the language.  (The
> > same idiom can be used with Calendar, but there are a few more
> > required caveats.
> 
> On Linux, this results in delays of 0. Even trying Ada.Real_Time.Tick
> (10 uS) was the same. At some higher value the behaviour changes so
> that you do actually get a delay: I tried
> 
>   Next := Next + Ada.Real_Time.Milliseconds (2);
> 
> for example, but all that happens is that you get one interval of 20
> mS and 9 intervals of 0 ms which of course averages to the 2 mS but
> isn't what we had in mind ..
 
    This is a horrible Unixism that you have to beware of.  Many Unix
systems
(and for that matter some other non-real-time OSs) have a fairly coarse
clock,
but successive calls to the clock are guarenteed to return different
values.  
For example, if the actual clock ticks at every 200 microseconds. the
first of
several successive clock calls will return an even multiple of 200
microseconds,
the next call will return immediately with a value incremented by one
microsecond,
etc.  Only when 200 clock calls have returned will the next clock call
wait for
the "real" clock tick.  Totally useless for real-time scheduling.  So
you both
need to know what the actual clock tick is, and which call gets to a
clock
that doesn't lie.  This is one of the reasons why Ada 95 added the
Ada.Real_Time
package--to provide access to an honest clock.

> I suppose things may be different over an RTOS.

   Depends on your definition of an RTOS.  Sun will tell you that
Solaris is an
RTOS, and if you know how to set it up, you may even get the correct
behavior,
depending on which Solaris version you have.  But from experience, do
not believe
anyone from the OS vendor, no matter how competant they seem.  The
heartstone tests
do a very good job of separating the sheep from the goats.  There are
implementations
out there which will do what you want, but among other things, you have
to read the
documentation carefully.  For example, you can produce a real-time
executable for
Solaris which, if run as root, will produce correct results.  But run it
as a user
process, and you won't get error messages, just incorrrect operation. 
(For example,
setting priority will "succeed" i.e., not raise a signal or return an
error code, but
it will not change the priority...)

Re: Timers in application (again)

[Frode Tenneboe]

(just got my newsfeed back - seems to be missing a few articles in this
thread though)

Ted Dennison <dennison@telepath.com> wrote:
: Simon Wright wrote:

:> Solaris runs with 10 mS ticks out-of-the-box. You can easily set this (2.6
:> and later) to 1 mS (set hires_tick to 1 in /etc/system).

: So both 20 and 50Hz should be achievable "out of the box". Frode can go check
: /etc/system to see if the default has been modified.

The default has not been changed.

Would changing to a hires tick improve reliability when I don't want/need
granularity of <10mS?

Must I run as root on solaris to get the expected behviour? It appears
as it works better for root but I have not tested heavily.

 -Frode
-- 
^ Frode Tenneb�                    | email: ft@edh.ericsson.se      ^
| Ericsson Radar AS. N-1788 Halden |                                |
| Phone: +47 69 21 41 47           | Frode@IRC                      |
| with Standard.Disclaimer; use Standard.Disclaimer;                |

Re: Timers in application (again)

[Simon Wright]

Frode Tenneboe <ft@alne.edh.ericsson.se> writes:

> Ted Dennison <dennison@telepath.com> wrote:
> : Simon Wright wrote:
> 
> :> Solaris runs with 10 mS ticks out-of-the-box. You can easily set this (2.6
> :> and later) to 1 mS (set hires_tick to 1 in /etc/system).
> 
> : So both 20 and 50Hz should be achievable "out of the box". Frode can go check
> : /etc/system to see if the default has been modified.
> 
> The default has not been changed.
> 
> Would changing to a hires tick improve reliability when I don't want/need
> granularity of <10mS?
> 
> Must I run as root on solaris to get the expected behviour? It appears
> as it works better for root but I have not tested heavily.

If you use the default tick, you will delay (or delay until) for at
least 10 mS; in practice, this means 20 mS intervals, other things
being equal. If that's OK, fine.

Changing the tick doesn't cause any problems we are aware of, unlike
Linux where the system does seem a little inclined to lock up (once
per 3 weeks, perhaps) -- but the standard libraries weren't rebuilt,
so there may be some dependencies on the actual value of HZ
(<asm/param.h>).

With GNAT, a tasking program run as root will use the RT dispatching
class, and priorities will work. Run as any other user, priorities
will not work (and the OS will do its own round-robin or whatever
scheduling).