Re: Using "delay until" in real-time

[Keith Thompson <kst@cts.com>]

Ted Dennison <dennison@telepath.com> writes:
[...]
> 1/60 works out to about 0.016(6-repeating). That can't be accurately
> represented in an IEEE floating-point register. So what we get is
> something like 0.016667 (forgive me if I'm rounding the wrong digit).

I think you're assuming that type Time is a floating-point type;
either that, or you're (inappropriately) using floating-point to store
time values.  It's more likely to be fixed-point.  If you're using
Gnat, Ada.Real_Time.Time and Ada.Real_Time.Time_Span are both derived
from Duration, which is a 64-bit fixed-point type with a Small of
exactly 1.0e-9 (one nanosecond).

The value 1.0/60.0 is still not exactly representable; it's going to
be either 0.166666666 or 0.166666667.

> That rouding error slowly accumulates over time, until after about 52
> seconds our poor Executive task skips a tick. On our system ticks come
> at 240Hz, so that means that once every 52 seconds the executive
> scheduler waits about 20ms instead of 16.6(6-repeating)ms. Of course
> this wreaks havoc in our hard-realtime system.
> 
> So the question is, what's the best way to solve this problem? Here's
> what we came up with so far:
> 
>   o  Use the RTOS' "taskDelay" function to delay the appropriate amount
> of ticks (4).
> 
> I don't like this one, as its a non-Ada solution, and thus renders our
> scheduler non-portable. Its also succeptable to drift if something
> causes an extra tick to pass before we get to the taskDelay.

Is the scheduler intended to be portable?  If the design of the
scheduler depends on the underlying 240Hz clock tick, perhaps you
should just bite the bullet and delay for 4 ticks.

> Since this problem should happen to anyone using "delay until" with an
> iteration rate divisible by 3, and 60, 30, and 15Hz are common rates in
> the industry, I can't be the first person to stumble on this problem.
> How does everyone else handle it?

If you're using Gnat, it will happen to anyone with an iteration rate
that's not a whole number of nanoseconds.  For other compilers, it may
happen with an iteration rate that's not a multiple of a power of 2.0,
depending on how the time types are implemented.  (In either case,
that includes iteration rates divisible by 3.)

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.