Date: Fri, 25 Apr 2003 22:24:52 -0400 From: Bill Moran <wmoran@potentialtech.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: freebsd-questions@freebsd.org Subject: Re: Time Problem in 5.0 Message-ID: <3EA9EDF4.9000702@potentialtech.com> In-Reply-To: <20030426010835.GB5143@dan.emsphone.com> References: <20030424214413.GC90097@grimoire.chen.org.nz> <20030425091950.GA558@dhumketu.homeunix.net> <3EA92FF1.30809@potentialtech.com> <20030425184813.GA674@dhumketu.homeunix.net> <448ytye5xj.fsf@be-well.ilk.org> <3EA9925E.30201@potentialtech.com> <20030425203301.GU45035@dan.emsphone.com> <3EA9D2EC.3040304@potentialtech.com> <20030426010835.GB5143@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >>>>removed. Opinions? >>> >>>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: http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-a-faq.htm) 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. -- Bill Moran Potential Technologies http://www.potentialtech.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EA9EDF4.9000702>