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>