On Fri, Aug 10, 2018 at 07:46:46PM +0200, Fekete Tamás wrote:
verify the output. note: ntpd has to run!). Assume, that you choosed the proper
time source for sync, so it means that the mechanism which steps your clock
locally is broken. It can be battery reasons on the mainboard, temperature can
also influence (but not too much nowadays), if you use virtual machine, that
matters a lot, as it gets the CPU cycles from the host machine, and it's inner
time stepping highly depends on the CPU time given by the host, finally I have
never read anything about the effect of overclocking the CPU, it might have
also effect on this, but test should be run to be sure.

It's also really bad to run more than one time synchronization at once--they'll tend to confuse each other and cause random time shifts.

Ntpd has higher threshold to step the clock.
"After some time, small offsets (significantly less than a second) will be
slewed (adjusted slowly), while larger offsets will cause the clock to be
stepped (set anew)."
Source: http://www.ntp.org/ntpfaq/NTP-s-algo.htm

This isn't true on ntpd startup; it'll step the clock to get it close and slew thereafter. The only case where this a problem is if there are major issues with the local clock. (Which generally means you have bigger problems.) You may be thinking of the behavior where ntpd will exit on startup if the time is too far off. Using the -g option causes it to just set the time and carry on. (There are pros and cons to both approaches.)

Mike Stone

Reply via email to