From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 12:31:41 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 7A75416A4CE for ; Sat, 24 Jan 2004 12:31:41 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54F2543D2F for ; Sat, 24 Jan 2004 12:31:40 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i0OKVD82037266; Sat, 24 Jan 2004 12:31:40 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i0OKVD8A037265; Sat, 24 Jan 2004 12:31:13 -0800 (PST) (envelope-from dillon) Date: Sat, 24 Jan 2004 12:31:13 -0800 (PST) From: Matthew Dillon Message-Id: <200401242031.i0OKVD8A037265@apollo.backplane.com> To: "Poul-Henning Kamp" References: <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 20:31:41 -0000 :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). The problem with the timecounters is that they create incredible inconsistencies depending on which counter you use, various pieces of hardware, your hz frequency, and the phase of the moon. The timecounter code is ridiculously complex and unnecessary junk and I will be ripping it all out soon. Every last bit of it. I'm just going to use the 8254's timer 0 for a general variable reload interrupt timer feature for which the hz tick will only be one compoenent, and either timer 1 (speaker gated off) or timer 2 to calculate the elapsed time in the timer 0 interrupt or from other places. The other timers, if available and considered more stable, could be used as a passive PLL to compensate for the 8254's drift but that's as far as I will go. By guarenteeing that the timer 0 interrupt rate is always at least full-counter-load divided by 3 (18.3ms), absolutely nothing fancy need ever be done to figure current real time from, e.g. 8253 timer 1 or 2 if they are set with a full count reload. No apic timer. No acpi timer. No TSC garbage. none of that. -Matt