On x86, which timekeeping source is most accurate?

[Primis]

For the sake of counting time in say, miliseconds, which timer is most accurate?
IBM compatibles being a constantly evolving goliath, there is more than one source of this information, there is i8254 PIT, the real time clock's own timer, the HPET, and probably more. My main question is not which would be the most compatible, but more of a theory question of which has the best accuracy (least drift)

[klange]

As a preface, we need to establish the difference between accuracy and precision when it comes to clock sources.

Accuracy is how close to real time you are on average, or as you say, what has the least drift. A clock that can tell you when an hour, or a day, or a year has passed and be very close to those time periods is accurate.

Precision is how tightly packed things are. A clock that can tell you when very tiny periods of time has passed is precise.

The two characteristics are very often in opposition - error compounds.

The HPET, for example, has precision right in its name. An HPET is good for when you need to time very small periods, but is not necessarily accurate over longer periods.

Another clock that is precise is the TSC. TSCs in a number of early x86/x86-64 processors had issues with consistency in different power modes, or across multiple CPUs/cores, but for at least a decade or so Intel and AMD CPUs have had constant and invariant TSCs. On such systems, Linux prefers the TSC as the primary clock source. As an aside, APIC timers are generally TSC-linked, so they're effectively the same clock but as an interrupt source.

But, neither of these are necessarily accurate over long times (though they are really good!), and if you turn off the computer you lose track of time.

This is where the RTC comes in. x86 CMOS RTC is generally good for accuracy, but not precision. While you can get it to generate interrupts at up to 8kHz, maybe even 32kHz, you can only reliably read it at 1-second precision, so you have to keep track of those higher-precision numbers yourself if you want them, and at that point you're better off with something else.

And then there's the PIT, which is... really not that bad as a clock source? Generally they're within 1 or 2 seconds of drift each day, which isn't too bad. But they have their own oscillator that operates at a much a looser frequency than an HPET or TSC, and they don't have passive counter options like the HPET, TSC, and RTC.

But we've neglected one clock source: NTP. If you have access to a network, NTP can offer significantly better accuracy than an RTC, better precision than the readable counter in the RTC, and doesn't require a battery backup or active power consumption to keep time. Referencing Linux as an example again, a typical x86 setup will use the TSC as the local clock source, use the RTC as a boot timestamp until network is available, and use NTP to regularly synchronize for accurate time.

So what's the most accurate clock on x86? The network card.

tldr: lol they're all actually about the same as they typically all use the same crystal source (or at least the same type of crystal), so expect ~20ppm (~2s/day) for anything. If you want accuracy, use NTP.

[rdos]

I agree that NTP is the most accurate, at least provided you have a low-latency (or at least consistent latency) Internet connection. NTP also puts high demands on the network stack to give good results. In my home control system, I rely on the RTC for boot-time and NTP for real time. However, you also need a reliable clock source with good precision to achieve consistent time between reads of NTP time. TSC, HPET (or even PIT) can be used for that.

[BigBuda]

In some cases, you do have an option to use the a GPS chip as an additional clock source. Many laptops have it integrated into the 3G/4G adapter, many of them undocumented as per the laptop manufacturer's info (although easily discoverable from the adapter's own documentation). Baking support for it into the system might not be a bad idea. I've been using the GPS integrated into an HE910G present in an UTX-3115 gateway and the Ericsson present in a Toshiba Tecra S10 as an additional clock source for my network. It's actually something I'd really like to implement in my own OS for a few reasons.

[linguofreak]

In some cases, you do have an option to use the a GPS chip as an additional clock source. Many laptops have it integrated into the 3G/4G adapter, many of them undocumented as per the laptop manufacturer's info (although easily discoverable from the adapter's own documentation). Baking support for it into the system might not be a bad idea. I've been using the GPS integrated into an HE910G present in an UTX-3115 gateway and the Ericsson present in a Toshiba Tecra S10 as an additional clock source for my network. It's actually something I'd really like to implement in my own OS for a few reasons.

I've got a Raspberry Pi with a GPS chip hanging off the GPIO pins running as my local NTP server.

GPS needs about 5 ns precision to give the 5 ft location accuracy that it supplies, though that will fall off the further you get from the GPS chip. A GPS chip will typically give a top-of-second pulse (called Pulse Per Second or PPS) at 5 ns precision, jitter in handling the PPS signal and using it to correct the local time source will mean you get less than that at the NTP server, and then network latency will mean you get less than that at remote machines (WiFi introduces significantly more jitter than Ethernet).

[BigBuda]

Well, GPS satellites get their time from atomic clocks, same as stratum 0 NTP servers, so I don't know how significant any difference might be.

[linguofreak]

Well, GPS satellites get their time from atomic clocks, same as stratum 0 NTP servers, so I don't know how significant any difference might be.

There is no such thing as a "stratum 0 NTP server". Stratum 0 is reserved for the clocks themselves. Servers directly attached to precision clocks are stratum 1. GPS provides a very precise time source. Not only do the clocks on the satellites have to be precise, but the signals they send out must be timestamped very precisely so that any GPS receiver that can see enough satellites (four) to get a fix can know the current time to very high precision. The speed of light is within 2% of a billion feet per second, so every nanosecond of uncertainty in the time works out to a foot of uncertainty in position. Every microsecond of uncertainty is 1000 feet (300 meters) of uncertainty in position. GPS is specified for 5 nanoseconds / 5 feet of uncertainty. This is precise enough that a GPS receiver is regarded as a stratum 0 time source.

[BigBuda]

You're right. My confusion on the "0".