[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
TSC vs. HPET timecounter priority
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
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.
Main Index |
Thread Index |