On Tue, Mar 02, 2004 at 03:46:37PM +0000, John Haxby wrote: > Christopher Ness wrote: > > >>It's not clear to me why you would want to do this when configuring ntpd > >>is so easy -- just run redhat-config-date and check "enable network time > >>protocol". > >> > > > >Won't this stall the machine on boot if a network connection is not > >available? Don't be scared of cron. It is quite helpful, and if you > >have an application that requires all your machines to be somewhat close > >in time then is "enable network time protocol" good enough? > > > > > No. ntpd just attempts to run anyway. The initial ntpdate tends to > stall for a few seconds if the network connection isn't there, and if > that's too much then it's OK to just remove or empty the step-tickers > file. > >I agree with Tom that everyone should randomize their network accesses > >though. Thanks... (this little trick does help on real networks). > > > This is why ntp was created in the first place, well, one of the reasons. ... > > > >>If you want time synchronization on a dial-up connection (where you > >>aren't connected all the time), then there are ntp alternatives that do > >>a good job for that: chrony (http://chrony.sunsite.dk/) for example. > >>Just having npdate change the clock periodically isn't all that good -- > >>note that ntp (and chrony, I expect) use adjtime(2) to speed up or slow > >>down time to keep the clock adjusted. Some may have missed the announcement of changes to "ntpdate". "ntpdate" will no longer do the fast update that it once did. See the 'ntp' home pages and read the discussion. Because of this change to ntpdate people with volatile connectivity may need to revisit how the local clock is checked and set at boot/ network connect time. As the time on individual machines improves the need to randomize timed connections will need minor random delays with resolutions less than a minute. Today lots can be done in 60 seconds, no need to gang up on the first second of 60 ;-) When local clocks were sort of sloppy this hardly mattered but the quality of time that ntp can distribute absolutely changes the rules for pileups due to simple cron tasks. -- T o m M i t c h e l l /dev/null the ultimate in secure storage. mitch48-at-sbcglobal-dot-net
