From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 01:10:01 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 52CAE16A4CE for ; Sun, 25 Jan 2004 01:10:01 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1F6A43D1F for ; Sun, 25 Jan 2004 01:09:59 -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 i0P99juO050876; Sun, 25 Jan 2004 10:09:50 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 24 Jan 2004 20:45:14 MST." <20040124.204514.109171577.imp@bsdimp.com> Date: Sun, 25 Jan 2004 10:09:45 +0100 Message-ID: <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 09:10:01 -0000 In message <20040124.204514.109171577.imp@bsdimp.com>, "M. Warner Losh" writes: >In message: <200401242031.i0OKVD8A037265@apollo.backplane.com> > Matthew Dillon writes: >: No apic timer. No acpi timer. No TSC garbage. none of that. > >Maybe there are better ways to obtain these results. While not >directly releated to the nanosleep work, but just another point of >view. Most of the uglyness in timecounters comes in for the hardware independence. A major design goal was to make it as totally trivial at write the code necessary for a hardware-gadget to feed timecounters. I didn't want to see people who port to new archs run into code where they have to sit and do fixed-point binary math and worry about accumulative rounding errors and other weirdness. I also made the interfaces to the entire timecounter code very simple so that it could be replaced by an optimized platform specific implementation. (For instance on platforms which have a good calibrated nanosecond counter, s390 comes to mind). Knowing the precision you need to support up front means that you don't need the hysteric precision of timecounters. 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. A very good place to start is the "nanokernel" from Dave Mills, and I hope that Matt will consider it, even if I'm listed as co-author on the paper :-) It does suffer from a number of gremlins down in the weeniesecond domain, but I don't think Matt will need to worry about that but it would give him all the ntpd magic for free. -- 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.