Date: Tue, 6 Jun 1995 14:26:36 -0500 From: Jim Lowe <james@miller.cs.uwm.edu> To: bde@zeta.org.au, freebsd-hackers@FreeBSD.ORG Subject: Re: Interval timer/System clock Message-ID: <199506061926.OAA15779@miller.cs.uwm.edu>
next in thread | raw e-mail | index | archive | help
> Try Linux. I helped "fix" it too. Thats ok. I hope you can convience HP, Sun, SGI, DEC, IBM and all the other vendors that this method is the correct one. Otherwise it will be difficult to write generic programs that depend on select or the interval timer that require system clock accuracy. > > >and interval timers can't return at the time specified since that would > >break sleep. Actaully, in FreeBSD they return 10ms late. > > 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. Did you run the attached programs? The interval timer and select timers returns 10ms late -- consistantly. Specifing 10ms returns 20ms. Specifying 20ms returns 30ms. The test programs were written with Multimedia/polling type applications in mind. > This is the correct incorrect fix :-). It makes average timeout 5ms > too small instead of 5ms too large, and timeouts of 10ms may be reduced > to 0. I have never seen this behavior. Even on an unloaded system. I havn't even seen this behavior on an Alpha system where the processor is faster than a Pentium. Are you sure this case is possible? > > I think it is correct but haven't tested it. POSIX sleep is difficult > to implement using interval timers (the current version fails to restore > the alarm timeout correctly), but the periodic alarm is not relevant so > changing relitexpire() won't affect sleep(). So, I could fix the interval timer by subtracting 1 from the hzto() call in the realitexpire()... but what about select? With the current implementation I don't see a solution. Select will always return 10ms late. > > >Is there a clean solution that will fix this 1/2 tick problem and still > >allow select and the interval timers to work the way they do on other OSes? > >Or will FreeBSD be known as the system that is always 10ms late? :-) > > >... > >#define WAIT_TIME 10000 > > A wait time of 1 can be made to work right. That is riduculous. I have to specify a time < 10000uS to make 10ms work? A wait time of 1 means go as fast as the system clock can. With 100hz clock this means 10ms. However, on FreeBSD a time of 1 means 20ms. On a DEC system this means 5ms. This could be a cause of great confusion as Multimedia programs are developed. Typically, you want to poll several devices (network, frame grabber, sound cards) and update the screen every 10-20ms. The times don't have to be accurate -- but they have to be consistant. If a change isn't made to FreeBSD, then one would have to know about this and #ifdef every application for FreeBSD/Linux that uses select/interval timers. I take it you didn't try the test program I supplied. Try running it with a delay of 1uS. It still returns 0.02s or 20ms. Try it with a delay of 11000uS. It runs at 30ms. Something is broken! While it is possible to make the interval timers work by subtracting one from the reloaded value I don't think it is possible to make the select system call return on time with the current implementation. This will make it very difficult to write portable programs that rely on timings of accuracies of 10ms. -Jim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506061926.OAA15779>