Date: Sat, 4 Nov 1995 04:35:12 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, wollman@lcs.mit.edu Cc: current@FreeBSD.org Subject: Re: Time problems Message-ID: <199511031735.EAA15564@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511031735.EAA15564>