From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 11:48:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3466516A4CE for ; Sat, 24 Jan 2004 11:48:16 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A13E843D45 for ; Sat, 24 Jan 2004 11:48:14 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i0OJmD82036689; Sat, 24 Jan 2004 11:48:14 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i0OJmDpo036688; Sat, 24 Jan 2004 11:48:13 -0800 (PST) (envelope-from dillon) Date: Sat, 24 Jan 2004 11:48:13 -0800 (PST) From: Matthew Dillon Message-Id: <200401241948.i0OJmDpo036688@apollo.backplane.com> To: Don Bowman References: cc: 'Bill Moran' cc: current@freebsd.org Subject: RE: DragonflyBSD kernel clock improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2004 19:48:16 -0000 There are a couple of things going on here... it isn't all just fluff. First, the basic problem is that nanosleep() (aka sleep() aka usleep()) consistently sleeps for far longer then the requested time. It isn't jitter. It's consistently too long. While it is true that the spec allows for this, there isn't much of a point in having a 'nanosleep' call (emphasis on 'nano') which produces wildly varying results for small intervals. While I haven't completely solved this issue yet (I have to completely rewrite the timer code to fix it properly), it has been made far more consistent. Second, the fractional compensation code for the 8254. The 8254 runs at 1193182 Hz. If your 'hz' is set to 100, a fixed clock reload value of 11931 looses significant precision. The higher your 'hz' setting, the more precision is lost and the greater the error verses real time. If you are using the 8254 as your wallclock, then you will see a significant 'speed up' of the wall clock at higher hz settings. hz will wind up being far higher then the true frequency you requested. It isn't just jitter... it's a permanent error factor and it can create significant problems if you are running ntpd. So the fractional compensation code is designed to minimize this error. The fractional compensation code is NOT the PLL. Third, if you are not using the 8254 for your wallclock there will be persistent drift between clocks based on the 8254's hz-based interface (ticks) and clocks based on realtime. The PLL part of the fix simply compensates for the 8254's constant drift relative to the wallclock by occassionally adding one or subtracting one from the 8254's reload value. This third part is not really necessary, but it was fun to do so I did it. I like consistency and I hate sawtooth patterns. -Matt