Skip site navigation (1)Skip section navigation (2)
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>