On Fri, Sep 18, 2015 at 01:54:22PM +0000, Adri Koppes wrote: > If the clock is too far behind or ahead, doesn't chrony already step the > clock?
Not by default. You need to specify the threshold and the number of updates in which are allowed steps with the makestep directive in chrony.conf. Or you can do that manually with the makestep command from chronyc. > I don't think it makes sense to try and slew for a large difference. Sometimes it does, sometimes it doesn't. Things can break when the clock is stepped backwards. > This should normally only occur on boot or when chrony has been disconnected > from any source for a long time. Right. If you know the clock can be off by a lot, you should allow the step. The recommended minimal configuration does include a makestep directive allowing step in the first three updates. > I remember having chronyd running, using adjtime() to try to slew the clock > or adjust the frequency, but failing to do so. > I discovered when a previous instance of ntpd has set the kernel frequency > and phase offset, it did get reset when ntpd was terminated. > The kernel discipline then seemed to be trying to adjust the clock, while > chronyd was trying to do the same using adjtime(). > After resetting the kernel discipline manually, chronyd finally seemed to be > able to adjust the clock properly. > This was a long time ago and currently I always reset the kernel discipline > in the startup script, before starting chronyd. Hm, interesting. How long did you wait? A fixed frequency offset shouldn't be a problem for adjtime(). Maybe the PLL was still adjusting a larger offset with longer time constant and it would need couple hours to settle down. Or the frequency offset was set in the opposite direction and adjtime() had to overcome a larger drift. > > BTW, are you running the latest code from git? I have a FreeBSD system > > running in qemu and so far it seems to be working nicely, but I'm curious > > how > > it works on real HW. > > I am currently running the latest release version 2.1.1 on real HW in > production. > If the latest code from git is fairly stable, I can install it and try for a > while. > Currently I am running FreeBSD 10.2p3 amd64. I try to keep the code in git always compilable and working, so bisecting works, etc. If the new drivers work well, I think the current code is almost ready for a new prerelease. -- Miroslav Lichvar -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.