Re: [chrony-users] Large ppm clock slew rate

[Steven Sommars <stevesommarsntp@xxxxxxxxx>]

Thanks for the tick rate adjustment pointer.   ntpd doesn't adjust the tick value, as far as I know.  

The ntp.org NTP distribution does include the tickadj utility, which pokes /dev/kmem to adjust the tick value.

The context is the International Space Stations (see thread at http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2021-January/102525.html)

The externally observed frequency offset gradually increases from -500 to -1500 ppm with a repeating pattern.   This is bizarre, see the offset graph.  

If the cause can be determined, it may be correctable with ntpd or perhaps switching to chrony.

This particular host is running ntpd 4.2.8, so this isn't the right email list for detailed ntpd discussions.

On Tue, Jan 19, 2021 at 12:06 PM Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:

If your clock is out that badly then there is something very wrong with your
onboard clock or in the calibration of the clock initially

The linux kernel has two time adjustments, a fine on ( which has the 500PPM
limit) and a course one( which has the 1/10 sec/sec limit) Chrony uses both..
Ntpd just uses the fine one.

chrony measures the offset of the clock wrt a clock source and runs a linear
fit on the last N offset readings. It adjusts the clock rate to gradually
bring the rate to 1s/s with respect to standard (ewxternal ntp source(s).
The linear fit is tested to see if a linear fit is a reasonable fit to the
offsets. If not, it decreases N, the number of offsets used, until the fit is
reasonable (Not too many differences between the offsets and the linear fit)  with a single sign in a row).
At worst it uses just three offsets to fit to.  It grows N ( by one at a time)
until the linear fit goes bad, or until a maximum value of N is reched (I
think it is 64).

The documentation for chrony describes a lot of this. Then there is the source
code itself. Because of the linear fit, it can determine the residual offset
and the rate much more quickly and accurately than does ntp, with chrony able
to get sometimes more than a factor of 10 improvement over ntpd.
ntpd just uses a simple feedback loop.
(Note that when chrony alters the rate or the offset of the clock, it adjusts
the whole history of offsets it uses to fit by that change in offset and rate,
to keep the past data relevant to the current running of the clock.
)


William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

On Mon, 18 Jan 2021, Steven Sommars wrote:

>
> I have a Linux installation which may require clock slew rate > 500 ppm, which exceeds normal
> adjustimex limits.  Chrony lists a 100000 ppm maximum slew rate.  How is that done?
>
> Is there a document that describes chrony's clock discipline algorithm?
>
>