From owner-freebsd-hackers Fri Jun 2 07:59:44 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA08658 for hackers-outgoing; Fri, 2 Jun 1995 07:59:44 -0700 Received: from miller.cs.uwm.edu (miller.cs.uwm.edu [129.89.35.13]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA08641 for ; Fri, 2 Jun 1995 07:59:39 -0700 Received: (from james@localhost) by miller.cs.uwm.edu (8.6.10/8.6.10) id JAA23717; Fri, 2 Jun 1995 09:58:26 -0500 Date: Fri, 2 Jun 1995 09:58:26 -0500 From: Jim Lowe Message-Id: <199506021458.JAA23717@miller.cs.uwm.edu> To: bde@zeta.org.au, freebsd-hackers@FreeBSD.ORG Subject: Re: Interval timer/System clock Sender: hackers-owner@FreeBSD.ORG Precedence: bulk > From: Bruce Evans > 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. 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