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)
Weird. Now ntp does not do anything above 500PPM, so it may just be that the
ISS computer clock is badly calibrated so that the rest tick rate is out by
say 1000PPM, and initialy it tries to gradually increase the PPM to 500, and
then gives up. Ie, it might be interesting to set up a machine on the ground
where the tick rate is out by say 1000 PPM, and see if it behaves the same
way. Certainly chrony should be able to fix this, by adjusting the tick rate.
It is weird that it drift rate increases with time. Maybe a bug in ntpd?
I assume that the steps are offset steps introduced by ntp stepping the clock.
Why it would do so at different offsets is also strange.
ntp does not try to separately adjust the drift rate. It assumes that if it
tries to adjust the time offset by changing the drift, the rate of the clock
will automatically go to 1s/s.
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.
You might be able to manually adjust the tick rate with adjtimex(8) to bring
the drift of the clock into ntpd range and then normal ntpd would take over.
Or use chrony which would do that automatically. But I guess the problem is
that changing (ntpd->chrony) is wrapped up in far more bureacracy than is
change like a manual resetting of the tick rate.
But firstly, one needs to get a system on earth behaving the same way so one
can try experiments on it. Teh first one would be to manually adjust the tick
rate on some earthbound system so that the uncorrected drift is say 1000PPM
and then start up ntpd and see if it behaves similarly.
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 <un...@physics.ubc.ca> 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 |____ un...@physics.ubc.ca
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?
>
>
