Time Problem in 5.0
wmoran at potentialtech.com
Fri Apr 25 19:25:12 PDT 2003
Dan Nelson wrote:
> In the last episode (Apr 25), Bill Moran said:
>>Dan Nelson wrote:
>>>In the last episode (Apr 25), Bill Moran said:
>>>>I'm going to repeat myself here: ntpdate is depreciated. The
>>>>functionality in it is duplicated by ntpd. It shouldn't even be in
>>>>the 5.0 tree. I'm considering filing a pr to request that it be
>>>ntpdate has two nice features:
>>>1 - It runs in under a second. This is useful during the startup
>>> sequence, so you know all of your daemons come up with the right
>>> time. "ntpd -q" took 3 and 5 1/2 minutes to return my prompt on
>>> tests on two different machines.
>>That's because ntpdate is an unreliable hack of the ntp system. Read
>>some of these docs on reliable time-keeping any you'll understand why
>>ntpd takes so long, even with -q:
>>http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-a-faq.htm The use of a
>>single NTP server is never considered a good idea.
> During the boot process I could care less if I'm a half-second off.
> I'd rather not be an hour or a day off, though. I just want ntpdate to
> give me a reasonable clock for 5 minutes until ntpd gets itself
> synched. An unreliable hack is perfect.
You missed the point.
ntpdate takes a single server and syncs the time with it. If that server
is having difficulty of the sort that makes it's time unreliable, ntpdate
has no way of knowing that and could sync your time to something totally
ridiculous (such as 12:00 AM 1970). The NTP protocol (and ntpd) is
designed to prevent such an occurance by always checking all available
servers and throwing away any times that are radically different before
syncing. This is why it takes so long to sync, even with -q, because it's
validating the sanity of the data it's receiving.
I read somewhere that a survey of high-tier servers showed that a frigtening
percentage of them were unreliable. I'll see if I can find the exact
reference, but it escapes me at this hour (could be somewhere in here:
5 minutes is not a problem, which is why ntpd takes it's time slowing
pushing the time along until it gets to where it's supposed to be.
12:00 AM, Jan 1, 1970 ... that could be a problem if you ask me.
The only argument that I've heard that justifies leaving it be (IMHO)
is that it's contrib software.
More information about the freebsd-questions