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

[Bill Unruh]

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  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 _|___ 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 10 ppm maximum slew rate.  How 
is that
  done?
  >
  > Is there a document that describes chrony's clock discipline algorithm?
  >
  >

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

[Steven Sommars]

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  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 _|___ 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 10 ppm maximum slew rate.  How is
> that done?
> >
> > Is there a document that describes chrony's clock discipline algorithm?
> >
> >

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

[Bill Unruh]

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 _|___ 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 10 ppm maximum slew rate.  How is that 
done?

Is there a document that describes chrony's clock discipline algorithm?

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

[Bill Unruh]

t to add: If you look at the man page
man 8 adjtimex
(you need to install the adjtimex package) there are two adjustments.
One is the tick adjustment. Each incriment changes the tick time ( the time
the computer assumes a tick of the clock is worth ) by about 100PPM.

 -t val, --tick val
  Set the number of microseconds that should be added to the system 
time for each
  kernel tick interrupt.  For a kernel with USER_HZ=100, there are 
supposed to be 100
  ticks per second, so val should be close to 1.  Increasing 
val by 1 speeds up
  the system clock by about 100 ppm, or 8.64 sec/day.  tick must be 
in the range
  90/USER_HZ...110/USER_HZ.  If val is rejected by the 
kernel, adjtimex will
  determine the acceptable range through trial and error and print 
it.  (After
  completing the search, it will restore the original value
The other is the frequency
-f newfreq, --frequency newfreq
  Set the system clock frequency offset to newfreq.  newfreq can be 
negative or
  positive, and gives a much finer adjustment than the --tick 
switch.  When
  USER_HZ=100, the value is scaled such that newfreq = 65536 speeds 
up the system
  clock by about 1 ppm, or .0864 sec/day.  Thus, all of these are 
about the same:
   --tick  9995 --frequency  32768000
   --tick 1 --frequency   6553600
   --tick 10001 --frequency 0
   --tick 10002 --frequency  -6553600
   --tick 10005 --frequency -32768000
  To see the acceptable range for newfreq, use --print and look at 
"tolerance", or
  try an illegal value (e.g. --tick 0).

This is the one that is about plus or minus 500PPM So, chrony uses both tick
and frequency to adjust the rate of the clock, frequency for fine adjustment,
tick for coarse.
I believe ntpd only uses the frequency adjustment.


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 10 ppm maximum slew rate.  How is that 
done?

Is there a document that describes chrony's clock discipline algorithm?

[chrony-users] Large ppm clock slew rate

[Steven Sommars]

I have a Linux installation which may require clock slew rate > 500 ppm,
which exceeds normal adjustimex limits.  Chrony lists a 10 ppm maximum
slew rate.  How is that done?

Is there a document that describes chrony's clock discipline algorithm?