-----Original Message-----
From: Miroslav Lichvar [mailto:mlichvar@xxxxxxxxxx]
Sent: vrijdag 18 september 2015 15:36
To: chrony-dev@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated.
2.1.1-89-g3cd32ed
On Fri, Sep 18, 2015 at 12:20:51PM +0000, Adri Koppes wrote:
I agree the advantages of ntp_adjtime() outweigh the reduced slew rate.
I'd prefer the FreeBSD version to use only ntp_adjtime() with the kernel
frequency discipline, if the slew rate is below 500PPM.
I think what Bill and I are talking about is the rate at which a clock that is too
far ahead or behind can be corrected. On its own, it doesn't have to drift too
much.
If the clock is too far behind or ahead, doesn't chrony already step the clock?
I don't think it makes sense to try and slew for a large difference.
This should normally only occur on boot or when chrony has been disconnected from any source for a long time.
In my experience using adjtime() and ntp_adjtime() together can have
unpredictable results.
What problems did you see?
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.
If ntp_adjtime() was used only to set the kernel frequency to correct the
estimated drift and adjtime() was correcting only the phase offset, I think it
might work reasonably well. That's what recent versions of openntpd do and
it's also what the Linux driver in chronyd originally used to do.
I think you have a lot more experience on this field, so if you are fairly confident it work, please try and see how it behaves.
With a slew rate over 500PPM, the use of ntp_adjtime() and adjtime()
probably won't produce any better results than using only adjtime().
Agreed. The problem is if we wanted to use only adjtime() when the drift is
larger than 500 ppm, there would have to be a second driver (similar to the
one that was recently removed) and chronyd would have to switch between
them in runtime. I'd rather avoid that.
Agreed to. Having a second driver for probably such a rare condition doesn't make sense.
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.
Adri.
--
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.