From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 19:45:24 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 224D316A4CE for ; Sat, 24 Jan 2004 19:45:24 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF09F43D31 for ; Sat, 24 Jan 2004 19:45:22 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0P3jIET047473; Sat, 24 Jan 2004 20:45:18 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 24 Jan 2004 20:45:14 -0700 (MST) Message-Id: <20040124.204514.109171577.imp@bsdimp.com> To: dillon@apollo.backplane.com From: "M. Warner Losh" In-Reply-To: <200401242031.i0OKVD8A037265@apollo.backplane.com> References: <44827.1074974041@critter.freebsd.dk> <200401242031.i0OKVD8A037265@apollo.backplane.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: phk@phk.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 03:45:24 -0000 In message: <200401242031.i0OKVD8A037265@apollo.backplane.com> Matthew Dillon writes: : No apic timer. No acpi timer. No TSC garbage. none of that. We've found at work that while the 8254's timer tends to be the best universally available time keeping device, it is only as good as the quarts oscillator driving it. Other time keeping can be more precise. We've found that systems with APM disabled have a more stable NTP server when they are running on CPUs with TSC using the TSC timecounter, but about a factor of 5, mostly due to a reduced jitter in timestamping the PPS interrupts that we generate. Of course, we don't care one whit about SMP support for these systems. Maybe there are better ways to obtain these results. While not directly releated to the nanosleep work, but just another point of view. Warner