TSC vs. HPET timecounter priority

[Erik Fair <fair%netbsd.org@localhost>]

NetBSD has a problem with NTP time keeping on x86 systems which have TSC: if 
those systems have variable CPU clock frequency support for power consumption 
efficiency (e.g. SpeedStep, PowerNow), if or when the CPU frequency changes, 
the relationship between TSC and the ticking of real time changes. That screws 
up any kind of interval time & frequency measurement one is using TSC for.

The High Precision Event Timer (HPET) is intended to provide timekeeping 
independent of CPU clock frequency, and do a better job than the old 8254 timer 
chip one finds on ISA bus.

Right now, our kernel timecounter code takes the TSC over the HPET if both are 
present; it's a static "quality" value in a table structure. The result on 
systems with variable CPU frequency is poorer timekeeping. This can be measured 
if you're running ntpd; see the output of ntptime(1) and look for "frequency" - 
that number wants to be as close to zero as possible (it can be negative or 
positive). It's calculated over a long time baseline (hours of NTP 
query/response samples from your (hopefully carefully selected) NTP peers) and 
saved in /var/db/ntp.drift for persistence between reboots so it doesn't have 
to be recalculated from scratch every time ntpd is restarted. You should see 
this value change if you change the kern.timecounter.hardware sysctl setting in 
your system to one of the other sources, and wait, say, six hours or more 
(overnight ought to do it).

A quick google of NetBSD's mail archives shows a discussion of this issue in 
2009 on port-amd64, but apparently no code changes came about. An alternative 
implementation of a putatively more accurate timer device (the L-APIC) also 
independent of CPU clock frequency was suggested, but I don't see code for 
that, either.

Until something is written and committed, I suggest an easy change in 
timecounter "quality" for HPET to make it preferred to TSC if both are present.

Another way to handle the issue is for the TSC timecounter attachment code to 
also check for the CPU clock frequency variability features of the various 
CPUs, and adjust the TSC quality down (perhaps to zero?) if they are present.

I delve into x86 code as little as possible, but I've been in the guts of this 
stuff before, to deal with a mis-ordering of TSC attachment that I found when I 
was playing with an AMD Geode system some years ago, though that was before the 
timecounter code came in. I'm willing to get into it again if no one else wants 
to touch this, but I'd prefer a developer who is more temporally familiar with 
it to tackle it.

I believe we should deal with this before 6.0 ships.

        Erik <fair%netbsd.org@localhost>