Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Nov 1995 21:34:12 +0200 (SAT)
From:      John Hay <jhay@mikom.csir.co.za>
To:        bde@zeta.org.au (Bruce Evans)
Cc:        bde@zeta.org.au, freebsd-current@FreeBSD.ORG (FreeBSD-current)
Subject:   Re: Time problems
Message-ID:  <199511061934.VAA14050@zibbi.mikom.csir.co.za>
In-Reply-To: <199511031523.CAA11301@godzilla.zeta.org.au> from "Bruce Evans" at Nov 4, 95 02:23:25 am

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> >> 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.
> 
> Are you sure it takes <= 99 seconds?  I doubt that the hardware error is
> more than 1 part in 1000.
> 
> We need a more reliable method of slowing down i/o accesses iff necessary.
> In getit(), it is probably acceptable to add some dummy i/o's.  It may
> only be necessary to add a delay between the back to back i/o's (after the
> outb and before the first inb).  Try that (add one or more inb(0x84)'s).
I tried one and two dummy inb's there and it was better, but still below
99 seconds. Then I added an inb between the low and high inb's and then two
inb's and that seems to do the trick for getit(). It now take a little more
than 99 seconds for the 100 second delay.
> 
> >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...
> 
> You would need similar delays in microtime() for the non-pentium version
> to work.  Try adding such delays (`inb $0x84, %al' immediately after the
> outb).
I tried a few combinations up to two inb's after the outb and after the first
inb, but I still get negative numbers. I also tried Garrett's program and
apart from it coredumping sometimes the min value is always a negative number
-99 and worse.

On a more positive note, if I run with a "fixed up" getit() my cpu speed
gets probed correctly and then the pentium clock seems to be fairly accurate.

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?199511061934.VAA14050>