Re: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 2.1.1-89-g3cd32ed

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-dev Archives ]


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-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/