Date: Fri, 2 Jun 1995 10:43:38 +1000 From: Bruce Evans <bde@zeta.org.au> To: freebsd-hackers@FreeBSD.ORG, james@miller.cs.uwm.edu Subject: Re: Interval timer/System clock Message-ID: <199506020043.KAA19318@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>I have a question about the system interval timer. I am not sure why it >is behaving the way it is. >Shouldn't the interval timer in the system have a resolution of HZ rather >than HZ/2? I "fixed" hzto() by adding 1 to allow for the current partial clock tick. This stops usleep(10000) from returning after as little as 10 usec when the current clock tick expires. It causes usleep(1000000) in a loop to take an average of 2000000 - (a few) usec instead of 1000000 - (a few) usec. It breaks the it_interval arg to setitimer(). The fix may be to subtract 1 from hzto() in realitexpire(). realitexpire() is synchronized with the clock interrupt so it shouldn't compensate for partial clock ticks. Initial intervals of less than 1 clock tick could be handled more accurately by calling microtime() from hzto() to determine the current partial clock tick. However, microtime() is slow. >Also, it would be nice to have a faster interval timer (0.005 secs) for >various Multimedia/Real Time applications. I assume I can just add the line >``OPTIONS "HZ=512"'' to my configuration file, but if I do -- will >I break anything obvious? Yes, it will break time adjustment. <sys/timex.h> has many hard-coded assumptions that hz == 100, e.g., SHIFT_HZ = 7. This problem may only be serious if you use timed or xntpd or the undocumented option PPS_SYNC. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506020043.KAA19318>