From owner-freebsd-current Mon Nov 6 12:26:59 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA12112 for current-outgoing; Mon, 6 Nov 1995 12:26:59 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA12103 for ; Mon, 6 Nov 1995 12:26:52 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id HAA30357; Tue, 7 Nov 1995 07:22:11 +1100 Date: Tue, 7 Nov 1995 07:22:11 +1100 From: Bruce Evans Message-Id: <199511062022.HAA30357@godzilla.zeta.org.au> To: jhay@mikom.csir.co.za, julian@TFS.COM Subject: Re: Time problems Cc: bde@zeta.org.au, freebsd-current@FreeBSD.ORG 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. It still isn't clear what a general patch should do, but you can easily fix DELAY() for your h/w. >> > >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. Is this with xntpd or similar slewing the clock? I would expect only large errors of 10000 usec if the heuristic for handling counter overflow doesn't work. Bruce