On 8/13/2010 4:06 PM, Jerry Franz wrote:
> On 8/12/2010 8:03 PM, Les Mikesell wrote:
>> Warren Young wrote:
>>>
>>> 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.
>>
>> It's a bad idea in the general case. If you have scheduled jobs,
>> ntpdate may
>> jump the clock enough to miss the trigger or run them twice, where
>> ntpd always
>> tries to move the clock fractional seconds at a time so as not to let
>> that
>> happen. Plus, ntpdate does no sanity check at all - if the clock
>> source is
>> badly off, the client will follow blindly even if it goes to the wrong
>> century.
>>
>
> Whereas ntpd will simply quietly fail to sync at all if it is more than
> a few minutes off. ;)
No, it should sync with up to an hour's difference, but it may take a
while since it does fraction-second adjustments. The usual strategy
(and the Centos default)is to use ntpdate once at startup to cover for
bad hardware clocks or dead motherboard batteries, then start ntpd to
keep the time correct.
> I've used ntpdate to keep exceptionally balky machines in phase before.
Clients should never be 'balky' if you have a stable clock source -
perhaps with the exception of some virtual machine situations or
seriously bad hardware.
> If you do it frequently enough that the jump is never more than a second
> or two it works fine as long as you can tolerate the occasional out of
> order timestamp. Cron is sensitive only to the minute level and if you
> are paranoid about it, sync it at an odd time (something like 47 minutes
> after the hour) that just won't conflict with other cronjobs.
That's better than nothing, but in most situations, ntp should "just
work". I usually run it on routers and just use PCs as clients, though.
--
Les Mikesell
lesmikesell at gmail.com