On 12/11/2012 02:35 PM, Trevor Cordes wrote:
On 2012-12-10 Trevor Cordes wrote:
I have another system (not the same one with RTC problems). It loses about 1s every 1m in system time!!
I think I solved my own problem, after spending another hour on it :-(
A clue that I hadn't noticed (or noted in my post) is that ntpstat showed "unsynchronised" instead of the normal: synchronised to NTP server (208.73.56.29) at stratum 3
Also, the ntpq output indicated in its own obtuse way that it wasn't sync'd because there was no server with a * to the left of it.
No matter what I did, I couldn't get ntp to show "synchronised". I even would run ntpdate immediately followed by service ntp start and it wouldn't sync. And I confirmed ntpdate was indeed setting the clock perfectly. It made no sense! I knew it was *not* a ntp config error since it's config'd the same way as 20 other good boxes.
Anyhow, I started playing with kernel time sources and noticed this CPU (Petnium D) supports HPET.
cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm
Current setting was tsc
So I changed it to hpet echo hpet>> /sys/devices/system/clocksource/clocksource0/current_clocksource
Then ntpdate again
Then start up ntpd
BOOM! Instantly ntpd syncs to a source and ntpstat shows sync'd! WTF? Oh well, at least it seems fixed. Been 10 mins now and no time loss.
To get grub2 to change the kernel line so my hpet change survives reboot was another story... Grub2 looks nothing like grub! Can you say "over-engineered"?
Rather than changing the grub2 configuration, I think you can make that clocksource change permanent by adding the following line to /etc/sysctl.conf:
devices.system.clocksource.clocksource0.current_clocksource = "hpet"
There's a similar issue, apparently, under Xen, as described in this post:
http://forums.epicgames.com/threads/629267-Negative-Delta-Time-Linux-Xen-Pro...