David Lord <[email protected]> writes: >Richard B. Gilbert wrote: >> Rob wrote: >>> Richard B. Gilbert <[email protected]> wrote: >>>>> * On a system not locking stopping ntp and restarting having set the >>>>> drift file to -28, results in the drift going back to -400 over a >>>>> couple of hours - so not some odd start-up state that confuses the >>>>> control loop. >>>> This suggests that your local clock is defective! Most properly >>>> working hardware will generate an absolute value that is less than >>>> 100 and many will have an absolute value less than 50. >>> >>> I don't think so. This often happens with ntpd, also on systems with >>> a well working clock. There is some sort of problem with ntpd startup >>> as Unruh also explained. I have seen it many times. >>> >>> It is worse when you start to twiddle the config and shutdown/restart >>> ntpd often. Then it can take a very long time before it becomes stable >>> again. >>> >>> It seems that the official standpoint is to ignore or deny these >>> problems, >>> but that doesn't mean they cease to exist. >> >> I don't think NTPD was designed to be "restarted often". Chrony is said >> to be a better tool than NTPD if you want fast convergence. I haven't >> tried it since my systems run for months at a time. They would run for >> years if we didn't get two or three power outrages a year.
>I've started replacing ntpd on desktops and notebooks as it's not >really appropriate and "ntpd -q" or ntpdate would be sufficient. >It's just that ntpd was installed by default. Using "ntpd -q" before >starting chrony seems to give good results. Why would that do anything? Chrony itself has an option to step the clock on startup if the offset is too large ( user selectable-- if you want to select .128 sec, that is fine) >Of course having an existing good driftfile for either ntpd >or chrony will help a lot and if drift is much over 50ppm I >don't think ntpd is happy. Using one of methods to manually >adjust frequency to a low drift < 10ppm was my preferred >method but that seems to get fouled up in newer kernels by >the self calibration failing to get it right. >Back to original problem I'd have drift file saved to non >volatile storage otherwise I can't see ntpd being usable >if drift happens to be large (or only useful after days >with wild swings before possibly converging). This is a real problem with the recent kernel problems on Linux, because the system drift would change by 50PPM on successive restarts of the system. This would take ntp about 10 hours to correct. ( and chrony less than 1 hr) but is certainly a pain. >David _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
