| 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 Tue, 14 Nov 2017, James Feeney wrote:
On 11/14/2017 01:23 AM, Miroslav Lichvar wrote:
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.
If you were to ask me to describe to some other third person what it is that is now being reported by chronyd in these log messages, based upon my own understanding, derived from your descriptions and Bill's descriptions, I would be unable to provide any kind of precise explanation. I do not mean to be difficult or contrarian. I just do not understand what is being expressed with these "messages ... stacked on top of each other."
Each message says that the clock has suffered an unexpected shift in time from
what it should be at that time, and the message says tht that shift is being
corrected. The key works are "unexpected" and "shift". It may also have
suffered a shift in the past, but that past shift is being corrected already
and so it is not unexpected.
You seem to be describing some kind of log message that has no meaning in isolation - like an episode of a TV show that makes no sense unless you've seen the entire series.
Personally, I would say that that is just very bad User Interface design. In contrast, I believe that each log message should be "self contained", that it should have a clear and precise meaning, even in isolation.
Interpreted as above I believe it does have meaning in isolation. "Something
happened to the time and chrony will not try to correct it."
So far, after much back and forth, I have come away with an incomplete understanding.
Miroslav, if you really believe in the importance of this "stacked messages", "current remaining correction" concept, then please write a precise mathematical expression for what you are describing, beginning first with a complete list of variable names and their descriptions.
So far, the variables bandied about include:
1) the NTP server clock estimate
2) a not always present on-board Hardware Clock
That has nothing to do with chrony except when the system starts up. So never
worry about that.
3) the kernel's System Clock
4) some "hidden" chronyd internal clock
Chrony corrects errors by altering the drift of the clock (assuming that the
error is not so large as to demand a step of the clock).
5-10) the Six offsets between each pair of those "clocks"
Ignore the hardware clock. It is never of any relevance.
11-X) some, as yet, uncertain set of "partial offsets"
No such thing.
Y-Z) some, as yet, uncertain set of "cumulative offsets"
No such thing.
A-B) possibly some additional set of statistical "running estimates"
No such thing.
If I am able to understand what this "current remaining correction" thing is, I can better offer some opinion with respect to your questions:
The time is out by 5 sec. The rate of the clock is changed so that that 5 sec
offset should go to 0 in 100 seconds. The difference between that prediction
and the estimate of the NTP time is the "current remaining offset".
- 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?
Please be certain that each of these proposed "value" choices is included in the list of variable names and the list of equations.
I think that you first need to go and study the theory of how ntp and chrony
operate. It is really a bit much to be asking Miroslav to give you a complete
less in the theory of chrony.
I just like when chronyd reports what it is doing when it starts-up. Still, based upon my best guess, I don't think I care about any "remaining correction" that has no relationship to any "user visible" quantity. I assume that you know the story: "The answer is - 42! But, what is the question?" Does chronyd harbor some "hidden variables"?
Yes, many. The last N measurements of the offsets from the measured NTP time
from the server, corrected for changes in rate which have occured since they
were measured. These are used to make a least squares fit to estimate what the
difference in rate and time of the system clock and the NTP server's clock.
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.
So, you are actually talking about two different things? "acquired between updates", and "relative to [ the NTP server clock estimate ]"? But, "acquired", is relative to what? The NTP server clock estimate?
Relative to the corrected chrony time.
I'd suggest that two different things should be treated as two different things, with proper descriptions, so that they are not confused. Different log messages could say:
"System clock acquired a 2second lead between NTP clock estimate updates."
"System clock is leading the NTP clock estimate by 2seconds."
But then, what's the difference?
Learn how chrony operates.
--
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.