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