Date: Tue, 6 Jun 95 16:19:00 MDT From: terry@cs.weber.edu (Terry Lambert) To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, freebsd-hackers@FreeBSD.ORG, james@miller.cs.uwm.edu Subject: Re: Interval timer/System clock Message-ID: <9506062219.AA04975@cs.weber.edu> In-Reply-To: <199506061745.DAA18938@godzilla.zeta.org.au> from "Bruce Evans" at Jun 7, 95 03:45:07 am
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... "high resoloution" timers ... ] > No, they return an average of 5ms late for random calls and about 10ms > late only for synchronous calls, provided of course the application > making them gets scheduled enough - on a heavily loaded system it > may only run every few hundred ms. There is an implicit assumption here that the process will use the entirety of its quantum, and that an interval timer or select() expiry will thus be limited by the lbolt clock-preemption context switch. This assumption is wrong. Few programs run for the entirety of their quantum (ie: the full 1/HZ seconds), in the BSD (and UnixWare and Solaris and...) case, 10mS. A 5 or 10mS *guarantee* is acceptable, based on the non-RealTimeness of interval timers and select timeouts (which are in fact guaranteed by SVID III in the UnixWare/Solaris case to *be* RT events). A 5-10mS *average* is *NOT* acceptable. The implication of the select interface, that it takes a timeval struct, is that it has resoloution up to the system clock and process congestion frequency. Note: *system clock frequency*, not *system clock update frequency*. This distinction is apparently lost on UnixWare and Solaris 2.x for x < 3, where select(2) is actually select(3) built on top of poll(2) -- and poll(2) has a 10mS limit (which it's man page agrees with). As a result, UnixWare and Solaris are not SVID III compliant and do not meet the current licensing requirements for use of the UNIX trademark (lucky they got their licenses by buying them instead of via compliance, isn't it?). I have seen more than one "realtime" graphics application that *requires* a particular frame rate -- I've even written a game that *requires* a frame rate of 10 FPS and runs on X (Sean has seen it, even). To get this with a uniform smotheness, it uses a select timeout of 200uS. This works fine on SunOS, recent Solaris (2.3 or better), HP, FreeBSD 1.x, but still fails on UnixWare (who still use the buggered Poll to do their thing). The reason it works, of course, is that it takes much less than 200ms to do all the processing required for the next frame (I am a clever X programmer: I didn't use bitmaps, I used character sets and cell animation techniques). I have to say that a 5mS timing is plain unacceptable. Now, forgetting big dithering with the scheduler, the simplest fix is to change the run queue insertion order on an itimer or select timer expiry so that that process gets to run next. This is what Sun does. Barring causing a preemption of the running program (which you would do if you were truly worried about processes that were designed to consume their entire quantum), this yields acceptable performance. It should be noted that the system clock frequency on a Sun machine is accurate to 4uS on an unloaded system. For i86 Solaris on a 486/66, it's accurate to ~15-19uS. All that said, a fix for BSD, like a fix for UnixWare, will probably require a timer code rewrite to make it happy, and that's not in the immediate future, even for 2.1, as far as I know. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9506062219.AA04975>