| 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
]
Hi Miroslav,
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.
In my experience using adjtime() and ntp_adjtime() together can have unpredictable results.
With a slew rate over 500PPM, the use of ntp_adjtime() and adjtime() probably won't produce any better results than using only adjtime().
Besides, if your clock has a slew rate of 500PPM or more, something is probably very wrong with the internal clock.
As I said, one of the advantages of using the coarse adjustment is to bring
the drift rate close to 0, so that the fine adjustment has its full +- 500PPM
range to work with. As it is, if your clock happens to be 300 PPM out, you
only have +200 and -800 fine control to work with. It at least used to be that
the time calibration routine on Linux was a bit broken, so having the clock be
2-300 PPM out was not unusual, and was variable from boot to boot. Having the
coarse adjustment to automatically "zero" that out was useful.
Ie, being out by 300PPM did not indicate a problem with your internal clock.
It indicated a problem with the kernel, which finally got fixed after about 5
years or so.
I am not sure what the advantages of using ntp_adjtime() are. On Linux at
least, the coarse adjustment is used only for larger slew rates, and the fine
is used normally. I do not know what was done on FreeBSD.
Adri.
-----Original Message-----
From: Miroslav Lichvar [mailto:mlichvar@xxxxxxxxxx]
Sent: vrijdag 18 september 2015 13:36
To: chrony-dev@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 2.1.1-89-g3cd32ed
On Thu, Sep 17, 2015 at 11:04:07AM -0700, Bill Unruh wrote:
I am not sure what the consequences of this are, but if it limits
chronyd on Linux to 500PPM adjustment, it is a real step back. One of
the advantages of chrony has always been that it could rapidly adjust
the time by slewing, since it could slew up to a rate of 1/10. (ten
seconds to slew a second) and could remove the coarse adjustment of
the rate ( so if you clock was out by 300PPM on average, it could
still use the full 500PPM adjustment width of the fine control. ) To
go the silly ntpd rate limits of just 500PPM is to me a major change
in chrony and to me a backward step. Of course I may be misinterpreting this.
On Linux there is no change, the maximum frequency offset is still 10%. The driver was just refactored to allow sharing some parts of the code with other systems.
However, on FreeBSD and NetBSD, where adjtime() slewed by up to 5000 ppm, it's now only 500 ppm as their ntp_adjtime() doesn't allow more.
I think the advantages of using ntp_adjtime() outweigh the reduced slew rate, but there is still a possibility to improve the driver to use both adjtime() and ntp_adjtime() at the same time. adjtime() would be used only to make quick (but coarse) phase corrections.
I'm now working on the Solaris driver and the good news is that the ntp_adjtime() frequency can be set up to 32768 ppm, so going from the 65000 ppm adjtime() slew rate won't be that big a difference.
--
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.
--
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.
--
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.