Time Problem in 5.0

[Dan Nelson]

In the last episode (Apr 25), Bill Moran said:
> Dan Nelson wrote:
> > 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.

We're talking past each other.  On the whole, I agree with you. 
Ntpdate should not cron'ed.  Everyone should run ntpd on machines in a
temperature-controlled area, and verify their time sources.  But
ntpdate does serve a useful purpose during bootup.

> 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.

Actually, ntpdate takes as many servers as you pass it on the
commandline, and synchs to the best one based on three polls.  If it
can't contact any of them, it doesn't change the system's clock. 
During bootup, I want a fast timesync.  ntpd can give me accurate time
after everything's running.

> 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)

I have three NTP servers on my LAN that synch to my ISP's NTP servers,
which are either strat 1 or 2 servers that synch to multiple (>6 each)
good strat 1 sources themselves.  When a server boots up, ntpdate is
run with the IP addresses of those three internal sources.  I am
confident that if it doesn't give me a good time within 2 seconds, my
Ethernet switch is down :)

> 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.

If it extends my nfsd unavailability time during a server reboot from 1
minute to 6 minutes, that's a problem.
 
> The only argument that I've heard that justifies leaving it be (IMHO)
> is that it's contrib software.

Don't take away a useful tool just because clueless people might misuse
it.  Those same people will just as happily point ntpd to bad servers as
ntpdate.

-- 
	Dan Nelson
	dnelson at allantgroup.com