From owner-freebsd-current Mon Nov 6 11:53:16 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA10637 for current-outgoing; Mon, 6 Nov 1995 11:53:16 -0800 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id LAA10620 for ; Mon, 6 Nov 1995 11:53:05 -0800 Received: by tfs.com (smail3.1.28.1) Message-Id: From: julian@TFS.COM (Julian Elischer) Subject: Re: Time problems To: jhay@mikom.csir.co.za (John Hay) Date: Mon, 6 Nov 1995 11:53:03 -0800 (PST) Cc: bde@zeta.org.au, freebsd-current@FreeBSD.ORG In-Reply-To: <199511061934.VAA14050@zibbi.mikom.csir.co.za> from "John Hay" at Nov 6, 95 09:34:12 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2106 Sender: owner-current@FreeBSD.ORG Precedence: bulk so will a patch to -current come out of all this? my pentiium is estimated to be anything from 50 to 68MHz depending on the phase of the moon. > > > > > >> 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 >