From owner-freebsd-smp Wed Sep 22 8: 8: 3 1999 Delivered-To: freebsd-smp@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 3F53915442; Wed, 22 Sep 1999 08:07:55 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id RAA34338; Wed, 22 Sep 1999 17:07:10 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Luoqi Chen Cc: current@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Testers please! In-reply-to: Your message of "Wed, 22 Sep 1999 10:39:27 EDT." <199909221439.KAA05687@lor.watermarkgroup.com> Date: Wed, 22 Sep 1999 17:07:10 +0200 Message-ID: <34336.938012830@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199909221439.KAA05687@lor.watermarkgroup.com>, Luoqi Chen writes: >> people have found sufficiently many cases where the counters are >> not in sync after the BIOS is done. >> >I would really like to know how they managed to read the TSCs simultaneously, >or they resorted to some kind of statistical means (which I tried without >much success, maybe I will try later with some kernel hooks). The differences were pretty significant in offset, I havn't heard any numbers from them on skew, and I don't know of anybody who have tried to measure it. The trouble with N counters for N>1 is that you need to add code to synchronize AND syntonize them, you need code to make sure time is monotonic no matter what and yada yada yada. By the time you're done the i8254 doesn't look so bad after all... The ACPI counter is a good sized step in the right direction, they should have made it PCI clock driven, to get better resolution but I suspect the fact that they didn't is a sign that the PCI clock will be power munged at some point. For "general purpose" time a clock which is about the resolution of the IO busses is sufficient, the ACPI is a little low on frequency, but hey, it's miles better than the i8254, and the APM/ACPI will not fuck with it's frequency. For high resolution timing of "in-cpu" events, the TSC is still the way to go, and nothing (except SMP complexity) prevents it from being used for that, and it is probably pointless to convert the data to nanoseconds until the difference has been found in the end anyway. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message