From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 03:52:19 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 331A816A4DA for ; Sun, 25 Jan 2004 03:52:19 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6B9D43D1F for ; Sun, 25 Jan 2004 03:52:17 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i0PBqF82042053; Sun, 25 Jan 2004 03:52:16 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i0PBqFui042052; Sun, 25 Jan 2004 03:52:15 -0800 (PST) (envelope-from dillon) Date: Sun, 25 Jan 2004 03:52:15 -0800 (PST) From: Matthew Dillon Message-Id: <200401251152.i0PBqFui042052@apollo.backplane.com> To: "Poul-Henning Kamp" References: <50875.1075021785@critter.freebsd.dk> cc: wmoran@potentialtech.com 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: Sun, 25 Jan 2004 11:52:19 -0000 :If Matt is only interested in the PC platform with sufficiently :clued users, he can afford to make the choice of timekeeping a :boot-time or even compile-time fixable just like it is in so many :other UNIX kernels. Since you can't seem to stop attributing nonsense to my name, I'll elucidate a bit. The problem with the timecounter API is that it takes a kitchen sink approach to a problem that doesn't need a kitchen sink approach to solve. You are fiddling with fractional calculations on 64 bit values in three different numerical domains and you have switching logic to switch time counters on the fly that is all entirely unnecessary. ALL YOU NEED to be able to use a stable time source to calculate phase drift against, say, an NTP time source, is a relative count value. No microseconds, nanoseconds, seconds, or fractional 2^X junk is required. You certainly don't need to be calling nanotime() or friends. You have an API to do that, the problem is that it's mixed in with everything else. You just need a count value. That value, say from a TSC, can be used as the basis for phase drift calculations from things like NTP sources and then used to compensate the master clock (e.g. say the 8254) without 'switching timecounters' or doing anything fancy. In fact, you could use *several* time sources in parallel and choose the one with the lowest drift on an ongoing basis... all without having to mess with the system's core clock functions. Even without a temperature compensation resistor a crystal oscillator is not going to drift so quickly that software can't compensate for it a few times a second given another more accurate time source. There is no reason and no need to 'integrate' that alternate time source into the core of the system. It's unnecessary, it's a waste of time, and it introduces an excessive amount of complexity. So, yes, I am ripping timecounter out of DFly... because it's ridiculous overkill. -Matt