* Re: Timers in application (again) [not found] ` <x7vu2dxixhx.fsf@pogner.demon.co.uk> @ 2000-07-12 0:00 ` Robert I. Eachus 2000-07-12 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 4+ messages in thread From: Robert I. Eachus @ 2000-07-12 0:00 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Timers in application (again) [not found] ` <x7vu2dxixhx.fsf@pogner.demon.co.uk> 2000-07-12 0:00 ` Timers in application (again) Robert I. Eachus @ 2000-07-12 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 4+ messages in thread From: Robert I. Eachus @ 2000-07-12 0:00 UTC (permalink / raw) 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...) ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <396482A7.67F4E3E8@telepath.com>]
* Re: Timers in application (again) [not found] ` <396482A7.67F4E3E8@telepath.com> @ 2000-07-14 0:00 ` Frode Tenneboe 2000-07-14 0:00 ` Simon Wright 0 siblings, 1 reply; 4+ messages in thread From: Frode Tenneboe @ 2000-07-14 0:00 UTC (permalink / raw) (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; | ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Timers in application (again) 2000-07-14 0:00 ` Frode Tenneboe @ 2000-07-14 0:00 ` Simon Wright 0 siblings, 0 replies; 4+ messages in thread From: Simon Wright @ 2000-07-14 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2000-07-14 0:00 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <962353369.632238@edh3> [not found] ` <8ji8i7$7l5$1@nnrp1.deja.com> [not found] ` <962628027.67730@edh3> [not found] ` <3962B30F.969E7188@telepath.com> [not found] ` <x7vem582v66.fsf@pogner.demon.co.uk> [not found] ` <3963D186.DD987838@earthlink.net> [not found] ` <x7vsntn56v4.fsf@pogner.demon.co.uk> [not found] ` <3965DFB2.48371EAA@earthlink.net> [not found] ` <x7vu2dxixhx.fsf@pogner.demon.co.uk> 2000-07-12 0:00 ` Timers in application (again) Robert I. Eachus 2000-07-12 0:00 ` Robert I. Eachus [not found] ` <396482A7.67F4E3E8@telepath.com> 2000-07-14 0:00 ` Frode Tenneboe 2000-07-14 0:00 ` Simon Wright
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox