Garrett, Lots of red herrings are flopping in the stream here. If you want to set the clock quickly during boot, even if that might be hazardous, it is easyl to configure the ntpd configuration file to do this simply by tinker "tos maxsist 16" or something like that. The issue that concerns me is to replace ntpdate with somehting equivalent without requiring additional maintainer sweat..
Dave Garrett Wollman wrote: >In article <ywn9zld20zs5....@ntp1.isc.org>, >Harlan Stenn <st...@ntp.org> wrote: > > > >>I agree that ntpd -g is usually better than sntp (or ntpdate) to initially >>set the time, but the choice is between "Set the clock well, even if it >>takes a little time" and "Set the clock as quickly as possible and it may be >>wrong." >> >> > >What is actually needed at boot time is usually neither of these >things. It's more like "if the clock needs to be stepped backwards, >figure this out as quickly as possible, before any important services >start, accepting that there is some small chance that an additional >step in either direction may be required." It's a straightforward >trade-off of the sort engineers make all the time: there's a limit to >how much one is willing to pay (in initiailization time) to reduce the >likelihood of post-startup nonmonotonicity. This limit varies >depending on the application. > >-GAWollman > > _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
