From owner-freebsd-current Tue Jan 30 10:48:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA16399 for current-outgoing; Tue, 30 Jan 1996 10:48:22 -0800 (PST) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA16392 for ; Tue, 30 Jan 1996 10:48:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.6.12/8.6.5) with SMTP id KAA01434; Tue, 30 Jan 1996 10:44:24 -0800 Message-Id: <199601301844.KAA01434@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost didn't use HELO protocol To: uhclem@nemesis.lonestar.org (Frank Durda IV) cc: freebsd-current@freebsd.org Subject: Re: any ideas about this crash? In-reply-to: Your message of "Tue, 30 Jan 1996 10:18:00 +0700." From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 30 Jan 1996 10:44:24 -0800 Sender: owner-current@freebsd.org Precedence: bulk >[5] Worse than that, it is fundamentally broken on machines that have >[5]variable clocks (read: laptops and "green" PCs). The folks in Intel's >[5]P6 architecture group were shocked when they heard about what we were >[5]doing with the internal cycle counter..."It was never intended to be used >[5]that way!". >[5] At the very least, we should make it a compile-time option (defaulting >[5]to off!). >[5] -DG > >THANK YOU for saying that! I have been saying this for three months now >and was ignored even though I was probably arguing the same points and >looking at the same material out of Intels Oregon shop and from the chipset >vendors that you were. It makes a big difference when the P6 architects tell you this personally. > This Pentium internal timer is USELESS as a >TOD timepiece! Stop using it this way! It is only good for relative >measurements within the processors realm. > >Why give the Linux guys something else to razz us about? "USELESS" might be a little strong - it does have the merit of being a very fast, "accurate", and easy way to do time measurements. Unfortunately, it also has apparantly shown us that DELAY() has a bug of some kind as *all* of the machines I've tested come up with an incorrect calibration about 10% of the time I boot. The result it comes up with is actually wrong, too, as the statistics that the system generates later are clearly wrong (off by the same amount as the mis-calibration). It acts like some sort of rounding or arithmetic error that occurs during the calibration. -DG David Greenman Core Team/Principal Architect, The FreeBSD Project