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

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Fri, Nov 10, 2017 at 12:06:07PM -0800, Bill Unruh wrote:
> > 
> > Bill, I really do not understand what point you are trying to present here, with respect to the system log message.  I was only suggesting that the log message should be more clear as to, let us call it, "leading" and "lagging", "forward" and "backward".
> 
> You are requesting something further. You are also requesting a change in the
> value that is reported, not just making the sign of the error clearer. I am in
> perfect agreement with the request for making the meaning of the sign clearer.
> I am (perhaps) not in agreement with the value you want reported.

Same for me.

I think there are three separate questions:
- What value should be compared with the logchange threshold?
- What value should be reported in the message?
- How should be that value described in the message?

For the first one, I think we should keep using the new adjustment
that is applied on top of the remaining correction in order to avoid
reporting a large adjustment multiple times.

The reported value could be changed to include both the old and new
adjustment, and I think it would be well described as "system clock
ahead/behind".

Alternatively, we can keep reporting the change in the correction, but
that probably needs a different description than "system clock
ahead/behind". The old "system clock wrong" I interpreted as an error
that the clock acquired between updates, but "ahead/behind" I'd
interpret relative to NTP or UTC.

> > On 11/09/2017 09:05 PM, Bill Unruh wrote:
> > > 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.
> > 
> > Uhm - 4seconds, using Miroslav's example.  I am saying that the log message should report that the system clock offset is currently 4seconds.  I do not understand where you interpret a "but" out of that.  Miroslav has said that, presently, chronyd will report instead, what I understand to be a kind of "differential slew error", which, in this example, would be "1second", not "4seconds".  And, I was suggesting that the log message should *not* report "1second".
> 
> 
> There are two components of that 4 seconds. One is the three seconds which is
> already being corrected by the alteration of the slew. The other is the 1
> second which is a new offset. The three seconds is already being corrected,
> and to report it now again may be confusing.

Yes, the "system clock wrong by" messages were meant to be stacked on
top of each other. If we change it to report the current remaining
correction, it won't be clear how much the clock has drifted between
the messages. If the log had

system clock behind 10 seconds
system clock behind 9 seconds

the clock could have drifted by any value between the logchange
threshold and 9 seconds.

> > What is it that you are thinking that the log message should report?
> 
> From what Lichvar says, it seems that it now reports the 1 sec which is an
> additional uncorrected error. The measurments log already reports the raw
> current offset and the corrected
> offset.

The measurements log doesn't actually include the raw offset. I think
only the refclocks log has that. However, the remaining correction is
reported in the tracking log, so it should be possible to reconstruct
the raw offset in the measurements, statistics and tracking logs.

-- 
Miroslav Lichvar

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