On Thu, Jun 07, 2018 at 11:06:12PM +0300, Abdullah Ramazanoğlu wrote: > On Thu, 7 Jun 2018 19:32:35 +0100 Mike said: > > [--8<--] > > > In the end I used adjtimex -t 10065 -f 3058784 to speed the clock up a > > bit and that has allowed NTP to be able to keep it under control. > > > > So the issue with the slow clock appears to have been compenstated for > > but I'd be intersted to know what actually caused it. I've drawn a bit > > of a blank on that one and would be grateful if anyone could offer any > > thoughts? > > Could there be a race condition between hwclock(8) and adjtimex? > > IOW, there is a possibility that perhaps there was a drift rate set by hwclock > and this was the cause of excessive drift. Now that adjtimex counter balances > hwclock by an opposite drift rate, it can result in hwclock and adjtimex > fighting against each other. Just a possibility. > > I would have checked /etc/adjtime to ensure that no drift ratio set by hwclock. > More info about hwclock drift setting and /etc/adjtime format in hwclock man > page. > Thanks for the reply. I did do some fiddling in /etc/adjtime (setting the drift ratio to 0 to see if that resolved the issue, although it was unclear to me from the docs I read how and when this file gets read (I believe it's hwclock that reads it but when, other than on boot?) I did keep a copy of the original before I fiddled with it: 3.619663 1452036888 0.000000 1452036888 UTC I believe this means that it hasn't been updated since the begining of time and that there's a drift of 3s a day between the hardware and system clocks? I assume this should not account for the ~15 mins a day drift I was seeing? Regards, Mike.
Attachment:
signature.asc
Description: PGP signature