From owner-freebsd-current  Fri Nov  3 09:37:46 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id JAA19593
          for current-outgoing; Fri, 3 Nov 1995 09:37:46 -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 JAA19583
          for <current@FreeBSD.org>; Fri, 3 Nov 1995 09:37:34 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id EAA15564; Sat, 4 Nov 1995 04:35:12 +1100
Date: Sat, 4 Nov 1995 04:35:12 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199511031735.EAA15564@godzilla.zeta.org.au>
To: bde@zeta.org.au, wollman@lcs.mit.edu
Subject: Re: Time problems
Cc: current@FreeBSD.org
Sender: owner-current@FreeBSD.org
Precedence: bulk

>> You may have to wait for kernel changes (or write them :-) to use the
>> Pentium clock unless it is very close to an integral number of MHz.
>> Another problem with using it is that it breaks tickadj(8).
>> cpu_thisticklen() ignores the default value of `tick', so tickadj
>> can't be used to compensate for large errors in `pentium_mhz'.

>I do not see that this is the case.  From kern/kern_clock.c:

>                if (timedelta == 0) {
>                        time_update = CPU_THISTICKLEN(tick);
>                } else {
>                        time_update = CPU_THISTICKLEN(tick) + tickdelta;
>                        timedelta -= tickdelta;
>                }

Asumme for simplicity that timedelta is fixed at 0.  Then `tickadj -t
9999' changes time_update in the above from 10000 to 9999 on non-Pentium
systems but has no effect on Pentium systems.  tickadj would have to
hack on (a higher precision version of) pentium_mhz to achieve the same
effect on Pentium systems.  This is similar to the problem with jitter
in the non-Pentium microtime() that I mentioned previously.  Both
tickadj and adjtimeofday() adjust secondary variables but have no
effect on the primary clock frequency.  The scaling factor of
(1e6 / primary_clock_freqency) needs to be scaled by a factor of
(tick + tickdelta) /  (100000 / hz).

Bruce