Dear Colleagues, I think the extensions made by others to my comment were very valuable. Only thing I would like to add, that Fred's (original asker) problem is probably that time sync daemon can not do it's job in the background properly. Ntpd can not sync on startup or later and time async reaches 10 min, which is huge. So the problem here is two:
- the time stepper probably broken - and the time sync software can not do it's job properly. I would suggest to debug the second first, as you will need time sync even after you solved the first problem. Just some suggestion to this: - check the ntpd logs. If there is no dedicated log file to it, make one by editing the ntp.conf file - check if the drift file can be accessed and is writeable to ntpd - check the restriction section in ntp.conf file. Make sure the service is available on localhost at least on IPv4 - if ntpd runs, issue ntpq -p command and check it's output (compare it's output to any other linux machine with working time sync) Best regards Tamas Fekete 2018-08-10 22:53 GMT+02:00 Michael Stone <mst...@debian.org>: > 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 > >
