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

Re: Set your system clock

On Monday 14 February 2005 17:28, Roel Schroeven wrote:
>Gene Heskett wrote:
>>>Big reason #2: ntpdate doesn't guarantee a monotonically
>>> increasing system time (translation: it may set the clock
>>> backwards).  Unix systems don't like that.
>> Typically a crash recovery reboot will do exactly that when you
>> keep the hardware clock on UT.  In that event, the normal shutdown
>> does not have a chance to reset the clock to local time, and hence
>> is off by many hours on the reboot.  With ntpdate doing the crash
>> re-setting, my clocks get set backwards by 5 hours, but other than
>> whats been logged previously in this boot proceedure, everything
>> is still future tense to the processes that will run once booted.
>> However, other than trying to make sense of the system logs, and
>> an occasional squawk from smartd which is started before ntpd for
>> some reason here, this has been a zero problem problem.  Smartd
>> only fuss's once, resetting itself to the new time on the next
>> iteration anyway.
>The problem manifests itself when run as a cron job instead of at
> boot. If the clock is running fast, ntpdate will have to set it
> back for it to have the right time. That can mess up various
> things, such as strange errors while running make.

I think I've seen that a couple of times, but that was before I'd both 
shut down apic, and traded a cron job of running ntpdate hourly (not 
on the hour mind you) out for a finally functioning ntpd.

In no event did it actually screw up the kernel I was building at the 

>>>Big reason #3: ntpd only queries remote servers when it believes
>>> the local time might have drifted by more than an acceptable
>>> amount. If you have a very stable clock, then it will ask for the
>>> time fairly rarely.  A cron job knows nothing about this: it asks
>>> once per configured time unit, whether the local clock is likely
>>> to be dead accurate or has already slipped far out of sync.
>>>Big reason #4: if everyone put "0 * * * * ntpdate ntp.example.com"
>>>in their crontab, then once an hour ntp.example.com gets hammered.
>>>This also means that those answers are likely to be far more
>>>delayed (and therefore inaccurate) then they are during the rest
>>> of the hour.  Besides, the ntp.example.com admins would hate you.
>> No one who actually thinks about such nuances schedules such
>> important stuff at the top of the hour, every hour.  And that
>> tends to leave a slack spot at the top of the hour for those that
>> don't think, but just do it.  I expect its probably an mrtg
>> trackable peak though.
>Isn't it a little too optimistic thinking that most people will care
>enough and actually think about it?

Maybe, but if an old fart like me thought about it, how many 
youngsters might not.  I'm obviously outnumbered and thats generally 
a given since theres more 20 year olds than 70 year olds.  I just 
didn't think it was quite as black a picture as you painted.  People 
building servers will normally try to build to fit the width of the 
pipe and it all gets leveled out by the pipe if nothing else.

Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.33% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Reply to: