Re: [chrony-dev] new feature request: add "fast" and "slow" to "clock wrong" and "clock stepped" log messages

[James Feeney <james@xxxxxxxxxxx>]

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.
 
> Precisely, so why would you report that?

Indeed.  I do not see any reason to report that.

> 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".

>> 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?
>>
> 
> 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.

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?

> 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.

> 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.

> 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.

-- 
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.