Date: Tue, 31 Oct 1995 12:47:55 -0500 From: "Garrett A. Wollman" <wollman@lcs.mit.edu> To: "Justin T. Gibbs" <gibbs@freefall.FreeBSD.org> Cc: current@FreeBSD.org, wollman@FreeBSD.org Subject: Time problems Message-ID: <9510311747.AA29686@halloran-eldar.lcs.mit.edu> In-Reply-To: <199510311759.JAA08504@aslan.cdrom.com> References: <199510311759.JAA08504@aslan.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Tue, 31 Oct 1995 09:59:53 -0800, "Justin T. Gibbs" <gibbs@freefall.FreeBSD.org> said:
> I rebuilt my kernel a few days ago. I hadn't changed it for ~1 month.
> Ever since, my system clock is running exceptionally fast (1 hour gained
> every day). I know that this problem was brought up recently on the
> lists, but I expected xntpd to over come the problem with Pentium
> microtime. Unfortuantely that doesn't seem to be the case. Is anyone
> working on fixing this problem or know why xntpd is ineffective?
You must be one of the people who has a problem with the clock
calibration. There are two possible sources of error involved here:
1) The part of your chipset that emulates the timer/counter is
operating at the wrong rate (or the DELAY function isn't working right
for it).
2) Your CPU's cycle counter is not operating at the nominal
rate, or its rate in MHz is not close to an integer.
In talking to David Greenman about this problem, we found that one of
his machines which exhibits this problem suffers from (1). Other
people have suggested (2) for their motherboards. (David's
motherboard took about 12 seconds to perform a ten-second delay.)
Here's one thing which you might try:
In this function (in i386/isa/clock.c):
------------------------------------
calibrate_cyclecounter(void)
{
/*
* Don't need volatile; should always use unsigned if 2's
* complement arithmetic is desired.
*/
unsigned long long count;
__asm __volatile(".byte 0x0f, 0x30" : : "A"(0LL), "c" (0x10));
DELAY(1000000);
__asm __volatile(".byte 0xf,0x31" : "=A" (count));
/*
* XX lose if the clock rate is not nearly a multiple of 1000000.
*/
pentium_mhz = (count + 500000) / 1000000;
}
------------------------------------
Change the occurrences of `1000000' to `10000' and `500000' to
`5000'. This will reduce the calibration time, which makes it more
likely that the error in your clock will be small enough to get
rounded off. If that doesn't work, then just #ifdef out the body of
the function, which will cause the 8254-alike to act as the reference
for timekeeping.
Needless to say, on the three different motherboards we have here
(60, 100, and 120-MHz CPUs), we have never seen this problem, so it's
a bit hard to diagnose. For those machines on which the results are
reasonable, I expect timekeeping to be rather better than it was.
According to xntpd, my machine is within about 3 seconds per day,
which is about the same as it was before. (It's the precision, rather
than the accuracy, where this technique gives a benefit.)
-GAWollman
--
Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance.
Opinions not those of| It is a bond more powerful than absence. We like people
MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9510311747.AA29686>