| 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 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.
> In my experience using adjtime() and ntp_adjtime() together can have unpredictable results.
What problems did you see?
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.
> 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.
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.
--
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.