Date: Fri, 2 Jun 1995 09:58:26 -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: <199506021458.JAA23717@miller.cs.uwm.edu>
next in thread | raw e-mail | index | archive | help
> From: Bruce Evans <bde@zeta.org.au> > Subject: Re: Interval timer/System clock > > 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 Ahh.. this is why select and all the other timer calls return after 30 ms when one specifies 20 ms... and I thought my machine was just slow :-). > 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. I will have to take a look at this code... Thanks for the pointer. > > 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. Yup, need xntpd for the network/timing accurary between machines to decode MM packets in the correct order and in RT. Would it be resonable to propose a faster system clock than 10ms? The DEC hardware seems to run somewhere around 5ms which would give you an accurate user level clock at 10ms. Thanks for the pointers. -Jim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506021458.JAA23717>