From owner-freebsd-current Thu Nov 2 09:45:44 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA08556 for current-outgoing; Thu, 2 Nov 1995 09:45:44 -0800 Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA08323 for ; Thu, 2 Nov 1995 09:41:08 -0800 Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.6.12/8.6.9) id TAA00119; Thu, 2 Nov 1995 19:29:40 +0200 From: John Hay Message-Id: <199511021729.TAA00119@zibbi.mikom.csir.co.za> Subject: Re: Time problems To: bde@zeta.org.au (Bruce Evans) Date: Thu, 2 Nov 1995 19:29:39 +0200 (SAT) Cc: current@FreeBSD.org, wollman@lcs.mit.edu In-Reply-To: <199511011730.EAA07621@godzilla.zeta.org.au> from "Bruce Evans" at Nov 2, 95 04:30:41 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1416 Sender: owner-current@FreeBSD.org Precedence: bulk > > >OK, I did that and the 10 second delay takes about 8.5 seconds and the 100 > >second delay takes about 88 seconds. Here is the first part of dmesg: > > Urk. > > >Now how do I go further to find out where my problem is? > > Perhaps the 8254 clock is being accessed too fast. Try adding some delays > before each inb() and outb() in clock.c:getit(). Count to 100 or so to > get at least 1 usec delay. I added "for(x=0;x<100;x++);" between the inb and outb instructions and now the 100 second delay takes 98-99 seconds. So this is now much closer. It is also being probed as a 90MHz processor now. So it looks like this helps. > > If pentium_mhz is set to 0, then microtime() uses essentially the same > method as DELAY(). It accesses the clock registers as fast as possible. > Errors as large as 15 in 100 might be noticeable if you run the following > program. You will have to adjust the constants 25 and 50 (perhaps to 0 > and 100) to filter out the uninteresting stuff. Differences of < 0 or > much less than the average value mean that there is a problem. The > program should calculate the average value to decide a good range to > filter... I ran your program with the pentium timer disabled and regularly got negative numbers. The numbers vary, but things that I got was -6, -38, -44, -17, etc... Does this bring me closer to a permanent solution? John -- John Hay -- John.Hay@csir.co.za