Hi,
I've got a FC3 machine where the system clock ADVANCES at a rapid rate which screws up the services I have running.
I've got a hardware router (Snapgear SME575) which exposes an NTP server to my network and I can successfully use ntpdate to update the clock as long as I do it every 2 minutes.
In the FC3 machine I have the following ntp.conf /etc/ntp.conf: restrict default nomodify notrap noquery restrict 127.0.0.1 server 202.173.151.129 driftfile /var/lib/ntp/drift broadcastdelay 0.008 keys /etc/ntp/keys
When I look at what NTP is doing I see:
# ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
fizban.zordah.n 0.0.0.0 5 u 31 64 377 1.038 -393692 29073.0
So from what I can NTP is working and can contact the NTP server on my router but the time is changing so fast NTP cannot keep up?
Has anyone experienced/solved this issue?
I looked at mine and I find that the offset and jitter are much smaller. From the following link, the offset should be less.
Now I do remember many years ago reading that if your system time is out by to much, it won't be updated. If your time is out, you may have to manually reset it. Also look at the drift file as if this is out, your clock will run at the wrong pace. You may have to delete this file and start again.
http://networking.ringofsaturn.com/Protocols/ntp.php http://ldp.paradoxical.co.uk/LDP/sag/html/x2883.html
Also, is your BIOS clock set to UTC or local time? This makes a difference from my experience. One test to make is to check the time in bios, shut the computer down and then check the time in bios after an hour. This will give you an indication if the hardware (bios) clock is running and how precise it is. If it is running pretty accurate, then I would suspect that the software clock is running fast/slow due to the drift setting.
I used to use "hwclock" in the past.
-- Robin Laing
