On Thu, 17 Mar 2011, Jung-uk Kim wrote:
On Thursday 17 March 2011 04:01 pm, Peter Jeremy wrote:
On 2011-Mar-16 16:44:08 +0000, Jung-uk Kim <j...@freebsd.org> wrote:
Log:
Revert r219676.
Thanks also. For extra kudos, how about adding a similar function
to allow the HPET frequency to be over-ridden. That is currently
the only timecounter that does not allow the user to compensate for
incorrect hardware frequencies.
I really hate the idea of adjusting timecounter frequency from
userland. I guess "use ntpd(8)" is not a good answer for some
people. :-(
I use ntpd, and also adjust the timecounter frequency so that:
- when the timecounter is the TSC, ntpd has less work to do. It
syncs faster and its adjustments are smaller, giving less jitter.
- there is only 1 place to change when the TSC frequency changes.
Instead of changing the driftfile and restarting ntpd to resync
after every frequency change, I set the TSC as accurately as possible
(normally to within 1 ppm for the current frequency setting), so that
ntpd can resync automatically just as easily as it can handle small
termperature-related drifts. If you use a sloppy DELAY()-based
calibration or a nominal frequency, then you can easily have an error
of 50 ppm or more. ntpd will take hours to resync with that. By
resync, I mean that the error is usually less than a millisecond and
has low variance.
- the TSC it is as accurate as possible for other purposes, irrespective
of whether it is used for the timecounter.
Bruce
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
