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 ]



On Tue, 7 Nov 2017, James Feeney wrote:

On 11/06/2017 09:17 AM, Miroslav Lichvar wrote:
From the other suggestions that have been made, I liked best "was
stepped backward/forward".

That's good too.

For example, if 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, a message will be logged that the clock is
wrong by 1 second. The question is which offset of the system clock
should be reported (4 or 1) and when it should be reported (abs(4) >
logchange or abs(1) > logchange).

Ahhhhh - too many small numbers - is the "1" from the "5-4" or from the "4-3"?

I do not understand in what sense the clock is then wrong by 1 second.  And, I am thinking that the log message should never say that - too confusing.  If I am understanding, you are saying that currently, a message like that would be logged - and maybe there should not be a message like that.  It is not immediately evident to me why a message like that would be informative.  It may be better to only log a simpler message, describing the *current* relationship between the system clock and the NTP server clock.

The system is drifting the clock so as to get rid of the 5 second offset. It
should have drifted it by 2 seconds by this time, so that time should have
read 3 sec wrong. But instead it is 4 seconds wrong. If one allowed the drift
to continue it would be 0 seconds wrong in 1 1/2 measurement periods. With
that same drift however, it would, at the end of the drift still be 1 second
out. Ie, the clock is now out by 1 second from the expected drifting clock.




There are at least the following options:
1. change the message to better describe what is behind or ahead
2. change the message to print the real offset of the system clock
   a) print it on each update as long as the offset is larger than
      logchange
   b) print it only when the change in the offset is larger than
      logchange

Thoughts?

If I am understanding, I think I prefer option '2.a)'.

What I don't like about 2.a is that if there is a large initial offset
and stepping is not enabled by "makestep", there may be a large number
of the "clock wrong by" messages in the log, even if everything is
working as expected.

I am guessing that you mean, if a slewing correction is used, that there would then be a log message for every instance in which a small change is made?  Yes, that would be too much unimportant information.

I was supposing that alternative '2.b)' would mean that no message would be printed saying anything about the system clock when the offset was less than logchange.  I may have misunderstood.  I'm thinking that something should be printed initially about the system clock offset, but then, subsequently, only "state change" events should be printed in the log.  For instance, if the system clock drifts and, for some reason, the offset exceeds logchange, or if, when slewing the system clock, the system clock has achieved synchronization.

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


Slewing is the expected behaviour. Stepping is not. Thus one would expect a
log warning on stepping but not slewing, is what I would expect.


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


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


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/