From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 11:54: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 94BCA16A4CE for ; Sat, 24 Jan 2004 11:54:16 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EB4343D45 for ; Sat, 24 Jan 2004 11:54:14 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0OJs1uO044828; Sat, 24 Jan 2004 20:54:01 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Matthew Dillon From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 24 Jan 2004 11:48:13 PST." <200401241948.i0OJmDpo036688@apollo.backplane.com> Date: Sat, 24 Jan 2004 20:54:01 +0100 Message-ID: <44827.1074974041@critter.freebsd.dk> 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:54:16 -0000 In message <200401241948.i0OJmDpo036688@apollo.backplane.com>, Matthew Dillon w rites: > 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. I think this was subject to Brucification last it was raised on our lists. > 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. Unless you have replaced timecounters this is not true. Timecounters are insensitive to how your Hz ticks, as long as it does it often enough. (You should probably pull in the code from -current though, the 4.x code has some marginal issues). > 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. Only if you replaced timecounters. > 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 is harmless but IMO also pointless. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.