[CentOS] Date drift and ntpd

Warren Young warren at etr-usa.com
Thu Aug 12 22:41:46 UTC 2010


On 8/12/2010 4:15 PM, John R Pierce wrote:
>    On 08/12/10 2:51 PM, Warren Young wrote:
>>
>> Only one server on a given LAN should be running ntpd.  It's overkill
>> for every machine to keep themselves synced with such a complex and
>> fussy server.  All the others should just call ntpdate or msntp every
>> hour or so as a cron job to keep their own time close to that of the LAN
>> time server's.
>
> I disagree.
>
> Simply setting a systems time at fixed intervals will result in
> discontinuities in delta time measurements.  if the systems local clock
> is fast, a given time will occur twice, and a delta between two time
> readings could be negative.    if the clock is slow, a delta between two
> readings would jump by whatever correction.

This is one of the points from the paper I referenced: there are three 
main uses for clocks, and a single implementation isn't appropriate for 
all uses.  Only an ideal absolute time clock would work for all three 
cases.  Since we don't have that, you have to consider your own case 
before deciding on a clock synchronization strategy.

The strategy I recommended is based on the fact that its worst case 
behavior (a small negative jump every hour) is not a problem for me.  If 
it is a problem for your application, you need a different design.

> Once an ntpd synchs and
> stabilizes to its reference, its very low overhead.

True only as long as it's being given stable time input.  See figure 5 
in the paper for the kind of wild, damped oscillations you get with ntpd 
when the input is not stable.

The time series plot is crystal clear, but don't overlook the fact that 
the IQR plots use different axes.  There's a 4x difference hiding behind 
that bad visual display of quantitative information.  (Yes, that's my 
inner Tufte you're seeing poking out there.)



More information about the CentOS mailing list