Unruh wrote: > "Richard B. Gilbert" <rgilber...@comcast.net> writes: > >> Unruh wrote: >>> "Richard B. Gilbert" <rgilber...@comcast.net> writes: >>> >>>> Martin Burnicki wrote: >>>>> David J Taylor wrote: >>>>>> Nero Imhard wrote: >>>>>>> Martin Burnicki wrote: >>>>>>> >>>>>>>> Why shouldn't ntpd be run e.g. on a laptop? >>>>>>> [...] >>>>>>>> And surely this results in the question which has been discussed here >>>>>>>> several times: why does it takes so long for ntpd to adjust an >>>>>>>> initial tiny offset of a few milliseconds? >>>>>>> In my understanding, ntpd was designed as a tool to discipline clocks >>>>>>> of systems that need (or need to provide) very accurate time, and not >>>>>>> as a general-purpose clock-setting tool. >>>>> The original (x)ntpd has been designed long time ago, when there was much >>>>> less computing power than today. Under those circumstances it may make >>>>> sense to think about running ntpd on a system, or not. >>>>> >>>>> Today's standard machines are so powerful that ntpd is a tiny application >>>>> (in the sense of resource usage, of course not in the sense of the work it >>>>> does). It comes by default with many Unix-like distributions which are not >>>>> only installed on servers, or if required for academic studies. >>>>> >>>>> The number of downloads of the Windows installer clearly shows that ntpd >>>>> also becomes more and more widespread even in the Windows world, and >>>>> presumably not only on servers. >>>>> >>>>>>> The requirements that would mandate the use of full-blown ntpd are >>>>>>> mainly found on systems that stay up and connected for long stretches >>>>>>> of time (time servers, measurement and monitoring systems, loghosts, >>>>>>> file servers, etc.). >>>>> Even systems which are running continuously for a long time may need to be >>>>> rebooted sometimes, or ntpd restarted, and I'm sure the operators would >>>>> appreciate if the time offset will decrease quicklier than it currently >>>>> does, which is clearly possible. >>>>> >>>> If you start with the -g option, the time is set initially and the error >>>> should be very small. Setting the frequency correction to the correct >>>> value is what can take a great deal of time. Restarting with -g and a >>>> valid drift file should allow ntpd to converge fairly quickly. >>> If only Linux had not screwed up the calibration of the system clock, so >>> that the drift rate varies by up to 50PPM on each reboot. Means it takes >>> about 10 hours for the system to recalibrate and settle down. >>> >>> >>>> What seems to take a great deal of time is a cold start. >>> Or a warm start with a "bad" drift file. > >> I'd be very cautious about using a drift file that was much more than >> one hour old. If the environment (temperature) has remained constant >> you are probably okay but the greater the length of time you are down >> the greater the uncertainty of the time you will start up with. > > On Linux these days, even a drift file that is 10 sec old is useless, since > the system clock drift rate changes by up to 50PPM over a reboot. > >
Too many cooks. . . . _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
