AMD 890FX/SB850 clock issue
I have seen this issue on two different motherboards using the AMD 890FX/SB850 chipset, an MSI 890FXA-GD70, and a Gigabyte GA-890FXA-UD5. These motherboards use different clock generators (a Realtek RTM880N-793 and an IDT/ICS 9LPRS477, respectively). I have not seen this inconsistency on previous Intel and Serverworks chipset based motherboards. This leads me to believe the issue is with the SB850, probably in how the BIOS sets up its internal PLLs.
The issue is that the system time counter which drives the operating system's Time Of Day clock while it's running (there's a separate RTC which keeps time when it's off) varies quite a bit from boot to boot. I believe this comes from the internal "8254" timer in the SB850, but maybe it's from the HPET in the north bridge - I'm running with Linux kernel 2.6.32. I've seen it range from -10 ppm to +70 ppm, and in between. An offset of +70 ppm means that without correction, the system would be losing ~6 seconds per day. I haven't run enough tests to determine if there is a particular granularity.
In the graphs below, the computer is syncronized via NTP to an accurate local stratum 1 NTP server (locked to GPS time). The stratum 1 server typically stays within +- 20 us (microseconds) of actual time, and is considerably more stable than the system represented by the graphs below.
What these graphs show is the time offset vs. the stratum 1 NTP server (in red), and the frequency offset required to keep the system in syncronization with the NTP server (in green). Normally, one would expect the frequency offset to be consistent between reboots. The temperature of the system is fairly stable, and the clocks are derived from a crystal oscillator, so well less than a 1 ppm variation is to be expected. No changes were made to the system which would affect timing while the data was being collected for these graphs.
This first graph shows the system, very stable, running in sync for 24 hours. Notice that the frequency offset stays in a very narrow range, right around -3 ppm.
In this second graph, the system was rebooted twice. The first reboot occurred shortly after the previous graph ends, around 00:10 UTC Nov 27. The frequency offset can be seen to be increasing rapidly from it's previously stable -3 ppm (shown on the first graph), and begins to settle around +47 ppm.
The system was again rebooted around 2:40 UTC, and this time it settles with an offset of around -23 ppm.
The next two charts were made a few days later. Here we see the system going from +70 ppm to -10 ppm. There were a couple of reboots before it settled, which is where the large spikes occur. NTP was also restarted a few times to confirm that the issue was caused by rebooting, not NTP, this appears as the 4 smaller glitches on the right of the graph, where each time the offset settles to the same level.
The final graph continues on from the previous. It begins with the system exhibiting very unstable timing, with an offset of ~ -11 ppm, and a variation of ~ 1 ppm. This was present on the previous graph, although the scaling makes it appear flat there. Compare this one to the first graph, where the offset fluctuates in a 0.2 ppm range. After another reboot, it settles at a much more stable -6 ppm.
My guess is that when booted, the BIOS uses the CMOS RTC to measure frequencies and set the SB850 PLLs to the desired frequency. It likely does this in a hurry, so it doesn't achieve very good accuracy, and certainly isn't consistent.