svn commit: r219700 - head/sys/x86/x86

[Bruce Evans]

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 <jkim at 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