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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d3c9f386a8038d3c X-Google-Attributes: gid103376,public From: "Robert I. Eachus" Subject: Re: Timers in application (again) Date: 2000/07/12 Message-ID: <396C8BBB.F7EFC25@earthlink.net>#1/1 X-Deja-AN: 645503716 Content-Transfer-Encoding: 7bit References: <962353369.632238@edh3> <8ji8i7$7l5$1@nnrp1.deja.com> <962628027.67730@edh3> <3962B30F.969E7188@telepath.com> <3963D186.DD987838@earthlink.net> <3965DFB2.48371EAA@earthlink.net> X-Accept-Language: en,pdf Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 963414758 63.24.57.173 (Wed, 12 Jul 2000 08:12:38 PDT) Organization: The MITRE Corporation MIME-Version: 1.0 NNTP-Posting-Date: Wed, 12 Jul 2000 08:12:38 PDT Newsgroups: comp.lang.ada Date: 2000-07-12T00:00:00+00:00 List-Id: Simon Wright wrote: > > "Robert I. Eachus" 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...)