Linux clock drift
I have a AMD Opteron system on a Tyan motherboard running Gentoo GNU/Linux (kernel 188.8.131.52) which serves as a NTPD server for a small network, and the clock on the system experiences moderate drift (~1 second/hour). DMA is turned on on the HD, and dmesg reports "Using tsc for high-res timesource"
I understand drift is unavoidable, but it seems excessive. I sync this system to public NTP servers when I can, but this system is isolated from the internet for many hours at a time(which is why it serves NTP to keep this network in sync...) so it is unrealistic to rely on NTP.
The system is on a custom battery-backed solution with high-quality pure sine wave output, and when I analyzed it, it was a slightly less frequency than standard wall power(but still within measurement tolerances)
Does anyone have any clue about why this clock is drifting? I am considering using a GPS source to re-sync the clock but I would much rather that the system be self-sufficent (not lose more than a second or two) per 24 hour period.
One second per hour is a _HUGE_ drift.
What is the precise motherboard model number that you're using?
The hardware clock on a motherboard is typically run by a 32.768 kHz crystal oscillator powered by the CMOS battery. If the battery is nearly discharged (battery age not to be judged by motherboard age!) you could expect to lose time. Since the hardware clock is only checked on startup and the software clock runs afterwards it is unlikely that this is your problem since you observe the time loss while the computer is running, not between reboots. The software clock is interrupt driven and it is possible that demanding software is introducing sufficient interrupt service latency accumulated over time to account for your lost time. If this is the case external resynchronization from a known timing signal may be your most viable solution. As you indicated since your machine is 'off the net' for extended periods GPS may be your best choice.
PS: Good thinking about the 60Hz supply frequency, obviously you're aware that digital alarm clocks and old synchronous motor driven wall clocks effectively count the AC line signal cycles to measure the passage of time, however that measurement probably wasn't necessary. Unless you're aware that your device behaves otherwise, (I'm not aware of any) consumer SMPS provide only DC voltages and possibly a fan tach signal to the mother board, so an off-frequency AC supply isn't your problem.
Yeah, the problem is most likely the demanding load as this NTP server also runs some heavy computational software that continually takes about 30-70% of the CPU.
The CPU is the AMD Opteron 244 (though there is only one processor) 1.8 GHz, and the mobo is the Tyan Tomcat K8S (S2850) with AMD-8000 series chipset. The motherboard is several months old, so the batt may be gone.
Since the time is lost while the machine is running battery age probably isn't a factor. Depending on the busy process's priority the high load level probably is your culprit. As an experiment run your computationally intensive application on another machine to leave your server unencumbered and examine the results.