| Re: [chrony-dev] new feature request: add "fast" and "slow" to "clock wrong" and "clock stepped" log messages |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
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 Thu, 9 Nov 2017, James Feeney wrote:
On 11/09/2017 02:22 PM, Bill Unruh wrote:
That is unclear. Chrony knows that it is out by a certain amount. That is why
it is slewing the clock, and in a few seconds or minutes the system time will
be exactly what it thinks NTP time is. It now finds it is out by a second.
Does it report that it is out by a second or by that second plus the three
seconds that it already is correcting.
What does that mean, "already is correcting"? Either the system clock current instantaneous offset is 1 second, 3 seconds, or 4 seconds, relative to the NTP server clock.
The three seconds is being corrected, meaning that the clock has been slowed
down so that say in 10 seconds it would be out by 0 seconds. It is a known
error and it is an error that, if everything is left as it is, will be 0 in 10
sec.
Precisely, so why would you report that?
Indeed. I do not see any reason to report that.
But you are claiming you should report that 3 sec.
The logs are not the place to give a complete description of the theory of
chrony operations. That would just be silly, verbost and totally confusing.
One could put that into the documentation.
Yes. So, probably not useful to have a log message that even tries to report that "differential slew error".
Why? Possibly because your naive expectation is "If the clock is out, fix it
immediately" But that is not what chrony does.
"Slewing" is a different thing from "fix it immediately". chronyd *will* step the clock when configured with "makestep", which is probably what you mean by "fix it immediately".
No, it will only make a step if the step size is larger than some value.
But, I don't actually have enough information to understand what is meant by "didn't finish yet". When, or how often, and in what manner is this "previous slew" measured? Is there some "current slew" that is distinct from a "previous slew"? Does a previous slew "end" before the system clock becomes synchronous with the NTP server clock?
chrony measures the offset of the clock by doing a least squared fit on the
past N measurements offsets, to determine what the best value of the current
offset is. Once it has that information it alters the rate of the clock so
that in something like DT*2000 seconds (where DT is that measured offset) the offset will
be 0. (ntpd makes that 2000 a minimum. chrony will slew so that the error
disappears in 10*DT if DT is very large and the DT is less than the value to
make a step.)
Previous meaning "previously begun". Chrony, and ntpd do not correct times by
stepping the clock. They correct it by slightly increasing or decreasing the
rate by which the clock is running, until they have corrected the error.
There always exists an "instantaneous offset", of the system clock relative to the NTP server clock, which is an easy thing to describe, under any circumstances.
No, it is not because all the measurements have uncertainties-- due to travel
time fluctuations, due to measurement accuracy, due to interrupt handling
fluctruations, etc. Ie, no you cannot know what the "instantaneous offset" is.
When a "new measurement" is made of a "previously begun" slewing process - increasing or decreasing the rate of the system clock - the log message should be clear as to the nature of that measurement. What was measured?
What is measured is the difference between the average of the time when the
ntp packet was sent out and when it was received again according to the local
clock , and the time when the
remote machine claimed to have received it according to the remote clock .
chrony keeps measuring its deviation from the ntp time, and slews the clock,
at various rates, to correct for difference. This takes place all the time.
So the system clock frequency is changed, rather than the clock value being increased or decreased with small discontinuous offsets greater than 2 counts. Clearly, that is a challenge for the kernel, since there is no variable frequency oscillator hardware, and some hardware counter will need to increment or decrement by 2 counts instead of by 1 count at some rate, generated using a second counter.
Yes, there is a variable frequency oscillator. Or rather the time in seconds
between the ticks of the cpu clock can be changed.
It tweaks it every time it makes a measurement.
Presumably, a measurement of the current instantaneous absolute offset of the system clock relative to the NTP server clock. I believe that that is - or would be - the intuitive interpretation of most users. The idea that this "measurement" reported in the the log message would represent something much more abstract - and obtuse - than that is - unfortunate.
No. In chrony it is the least squares linear fit of the last N measurements of
the offset that is used to estimate the current offset. Because the
instantaneously measured offset is beset by uncertainties that can be
"averaged out" by doing a least squares fit. N is chosen actively to make sure
that over that set of N measurements the offsets are well approximated by a
straight line with gaussian noise.
Unfortunately in order to get a good estimate, one HAS to use "abstract - and
obtuse" in your words, procedures. chrony's way of doing it is a factor of 3
to a 20 times better than ntpd's method according to measurements that both I
and Lichvar have made.
And not to all your questions. You really need to read about the theory of ntpd clock adjustment which is
that same to lowest order as that of chrony.
That would not hurt, but the issue I am raising is about the meaning of a simple log message, not about the theory of the network time protocol. This does not need to be complicated. I believe that it should not be *made* complicated.
But what is reported in the logs is precisely tied in with how chrony
estimates the uncertainties.
Note that if you want the raw measurements of the offsets look in
/var/log/chrony/measurements, and /var/log/chrony/refclock logs. There you
will be given the raw offsets of each measurement of the local clock against
the estimate of the time given by the remote server. If that is what you want
to look at, look there. In the tracking log, and in chronyc tracking and otherwise, the best estimate
of the current offset from the time of the servers is reported instead.
--
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.