From owner-freebsd-current  Wed Nov  1 01:08:14 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id BAA04423
          for current-outgoing; Wed, 1 Nov 1995 01:08:14 -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 BAA04397
          for <current@FreeBSD.org>; Wed, 1 Nov 1995 01:08:06 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id UAA24620; Wed, 1 Nov 1995 20:03:05 +1100
Date: Wed, 1 Nov 1995 20:03:05 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199511010903.UAA24620@godzilla.zeta.org.au>
To: jhay@mikom.csir.co.za, wollman@lcs.mit.edu
Subject: Re: Time problems
Cc: current@FreeBSD.org
Sender: owner-current@FreeBSD.org
Precedence: bulk

>OK, I changed the values in calibrate_cyclecounter() like suggested and now
>my time stay much closer to reality.

>My CPU even probe as a 90MHz processor!
>> CPU: 90-MHz Pentium 735\\90 (Pentium-class CPU)
>>   Origin = "GenuineIntel"  Id = 0x525  Stepping=5
>>   Features=0x3bf<FPU,VME,PSE,MCE,CX8,APIC>

>Can we get some kernel config option to do this or will I have to change
>clock.c after every ctm? Or will this get to be the default?

No.  Reducing the calibration time should just decrease the accuracy of
the calibration (and speed up the boot :-).  Find out which clock is
inaccurate or which part of the calibration routine is buggy.  Define
DELAYDEBUG to get some debugging code in clock.c.  It currently
generates delays of powers of 10 usec up to 10 seconds.  You could
increase the delats to 100, 1000, ... seconds and time them with a
stopwatch to see how accurate DELAY() is.

Bruce