Bruce wrote: > On Wed, 07 Dec 2011 23:56:08 +0000, Harlan Stenn wrote: > > > Bruce wrote: > >> I do run sntp to set the clock before starting ntpd (so I don't need > >> ntpdate). Setting the clock this way at least gets the time offset in > >> the ballpark before ntpd starts. > > > > OK, and exactly why do you need "the time offset in the ballpark before > > ntpd starts"? > > In the worst case, e.g. if the machine has been out of service for a > long time, ntpd will just quit if the initial offset is large.
Then use the -g flag, as is recommended for startup. > Short > of that, getting close to the right offset before starting ntpd means: > 1) processes that depend on reasonably-close time synchronization > (rsync, etc.) can proceed Again, the BCP I described earlier addresses this too... > 2) ntpd converges to a stable point that much faster (i.e. it has > less of an initial offset to remove) At the moment, the worst case for this is an offset that is just under 128ms, which will take under 5 minutes to apply at the standard slew rate of 500ppm. (64ms will take about 2.5 minutes' time to apply, etc.) More than 128ms will be stepped. > I use sntp (rather than ntpd -q or ntp-wait) because it's much faster > than the alternatives (life is too short for thumb-twiddling). And you might still get a backwards step in this case. The bottom line is that you have not communicated any information to me that indicates you have a *need* to set the time before NTP starts. The only possibly area is for an initial offset that is less than 128ms, and we're looking at a way to address that situation. H _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
