Re: NTP problem - Clock too fast for NTP to keep up?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Peter Kiem wrote:
Hi Robin,

With the time being so far out, ntpdate isn't adjusting the offset. The usage of hwclock --adjust may be necessary to get the /etc/adjtime to change.

This poses the question if /etc/adjtime is being changed?


It only seems to be updated when I reboot the virtual server. At least according to the timestamp...


As I don't use FC3 but FC1 I am going out on a limb here.

Actually mine is only updated at reboot time as well.

cat /etc/adjtime =

0.000296 1104421584 0.000000
1104421584
UTC

I think that your time isn't being adjusted as you expect. All the time checking that you are doing isn't changing the necessary variables as they are to far out to be updated automatically. You may have to manually update the clock for awhile until it is close enough to update automatically. I looked at my system and the file that is updated by ntpd is /var/lib/ntp/drift on a daily basis. My is -14.053.

As someone else has stated, the update times may be to close together. I would also think that the error is to high for this to be done automatically.

I would be tempted to manually adjust the time at intervals to bring the times closer. Then hopefully ntpd will work better. I don't know. VMware may be your biggest headache in this matter. It may not be time slicing between VM's to allow time accuracy to be this close. You may only be able to adjust your time on a daily basis, not by the minute.


From the man page for ntpd.

Under ordinariy conditions, ntpd adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities. Under conditions of extreme network congestion, the roundtrip delay jitter can exceed three seconds and the synchronization distance, which is equal to one-half the roundtrip delay plus error budget terms, can become very large. The ntpd algorithms discard sample offsets exceeding 128 ms, unless the interval during which no sample offset is less than 128 ms exceeds 900s. The first sample after that, no matter what the offset, steps the clock to the indicated time. In practice this reduces the false alarm rate where the clock is stepped in error to a vanishingly low incidence.


-- Robin Laing


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux