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

[Robin Laing]

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