Alan McKinnon wrote: > On Tue, 10 Jan 2012 13:02:38 -0600 > Dale <rdalek1...@gmail.com> wrote: > >> Florian Philipp wrote: >>> Besides, ntpd does not correct such large differences. It is not >>> designed to do this, especially on a running system. Activate >>> /etc/init.d/ntp-client. It will set the clock so that ntpd can keep >>> it in sync afterwards. You can start ntp-client on a running system >>> but it might lead to funny errors or crashes of applications. >>> Better add it to runlevel default and restart. Regards, Florian >>> Philipp >> >> Two things. One, you need to set the clock manually since it is >> soooo far off. I would do this: >> >> ntpdate -b -u pool.ntp.org >> >> then start ntpd. Second thing, if you are dual booting with windows, > > If he dual-boots with Windows then running ntpd at all is pretty > pointless. > > ntpd is designed to take a longish time to correct an offset, and to > creep up slowly on the correct time. The primary goal is that every > second on the wall-clock between now and when the time is corrected > will happen (i.e. it won't suddenly jump to the right time the way > ntpdate does). For a laptop/desktop (the only use case that would > dual-boot), the machine likely won't be up long enough to correct > largish errors. > > Servers with long uptimes should use ntpd, especially if it's apps > timestamp data. > Laptops and desktops should instead use ntpdate every one or few hours, > that is more suitable for those machines (usually they only care about > what the correct time is now). > >
Wouldn't it make more sense to get the clock set correctly on bootup with ntpdate, and then have ntpd keep things in line moving forward? Otherwise, every couple hours, you'd have your cron'd ntpddate jumping the clock around. I've had apps get stuck in infinite loops from retrograde clocks, and having it happen at the wrong time during a compile process has its own context-sensitive consequences.
