Date: Thu, 2 Nov 1995 19:29:39 +0200 (SAT) From: John Hay <jhay@mikom.csir.co.za> To: bde@zeta.org.au (Bruce Evans) Cc: current@FreeBSD.org, wollman@lcs.mit.edu Subject: Re: Time problems Message-ID: <199511021729.TAA00119@zibbi.mikom.csir.co.za> In-Reply-To: <199511011730.EAA07621@godzilla.zeta.org.au> from "Bruce Evans" at Nov 2, 95 04:30:41 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511021729.TAA00119>