From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f8311a3a7edd715 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2000-12-12 12:23:06 PST Path: supernews.google.com!sn-xit-02!supernews.com!news-x.support.nl!newsfeed.skycache.com!Cidera!cpk-news-hub1.bbnplanet.com!news.gtei.net!howland.erols.net!usc.edu!ragnarok.cts.com!thoth.cts.com!not-for-mail From: Keith Thompson Newsgroups: comp.lang.ada Subject: Re: Using "delay until" in real-time Date: 12 Dec 2000 12:22:46 -0800 Organization: CTSnet Internet Services Sender: kst@king.cts.com Message-ID: References: <915jl7$jt5$1@nnrp1.deja.com> X-Trace: thoth.cts.com 976652566 5755 205.163.0.22 (12 Dec 2000 20:22:46 GMT) X-Complaints-To: abuse@cts.com X-Newsreader: Gnus v5.5/Emacs 20.3 Xref: supernews.google.com comp.lang.ada:3006 Date: 2000-12-12T12:22:46-08:00 List-Id: Ted Dennison 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 San Diego Supercomputer Center <*> Welcome to the last year of the 20th century.