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 05:25 AM, Miroslav Lichvar wrote:
> So, if there is a large adjustment running and a new measurement says
> the offset of the clock is not what expect (e.g. the clock or the
> server has drifted for some reason), should we report by how much the
> adjustment which is still running had to be adjusted, or the total
> amount of the remaining adjustment? Currently, it's the former.

Well, my intuition and naive assumption would be that any allusion to a system clock offset was describing an "absolute offset", relative to the NTP server clock, and NOT relative to some chronyd internal process, which, in this case, would be the slewing process.  And I also naively would expect that other people would make that same assumption.

Any log message that was referring to some offset of the system clock relative to some clock *other* than the NTP server clock, in my mind, should require some very very clear and emphasized language.  Even then, how would that be worded?  I am still not clear about this offset that is being reported!  A log message would seem to require some wording as "involved" as the expression of your example: "the initial offset was 5 seconds and the system clock was already corrected by 2 seconds when another measurement is made, which says the offset of the system clock is now actually 4 seconds instead of the  expected 3 seconds."  I don't even know how often "another measurement is made", so I cannot put that offset error in a precise context.

And, why would anyone care about this "differential slew error"?  Is there some attempt being made to illustrate a possible hardware fault, for instance, where the system clock is drifting faster than the chrony slewing algorithm is able to track?  And then, if that were the case, I would expect a different log message, such as: "Unable to correct system clock - excessive drift."

>> So, there could be an initial message, for instance, "The system clock is leading/lagging the NTP server clock by N seconds", followed by one of two differing follow-up messages, depending upon whether the system clock is corrected by slewing or by stepping.  For slewing, there could be a message that simply says something like "Slewing the system clock forward/backward, correction started.", and for stepping, a message something like "Stepping the system clock forward/backward by N seconds."

> What value should be reported if the previous slew didn't finish yet?
> That's the normal case. It's just that the slew is rarely larger than
> logchange.

My instinctive answer is "always the absolute offset of the system clock relative to the NTP server clock."

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?

My intuitive assumption would be that the slewing process is simply initiated when chronyd is started, and that the slewing process changes its rate dynamically, however much is required to "catch up" the system clock to the NTP server clock, and that a single slewing process will continue until synchronization is achieved.  Does "slewing" work like that?  Or some other way?

I have no idea how often chronyd actually "tweaks" the system clock, whether chronyd is in a "slewing" state, or even in a "synchronized" state.  Is there some hard-coded maximum allowed offset before the system clock is "tweaked"?  Or is there a periodic "tweak" rate?  And is this "tweak" interval dynamically adjusted?  Is the system clock "frequency" automatically "scaled" by the kernel?  I know that those are kind of basic concepts, but I really don't know what chronyd is doing at that low level.

I'm appreciating your patience with this explanation...

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