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." 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. 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 3) the kernel's System Clock 4) some "hidden" chronyd internal clock 5-10) the Six offsets between each pair of those "clocks" 11-X) some, as yet, uncertain set of "partial offsets" Y-Z) some, as yet, uncertain set of "cumulative offsets" A-B) possibly some additional set of statistical "running estimates" If I am able to understand what this "current remaining correction" thing is, I can better offer some opinion with respect to your 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? Please be certain that each of these proposed "value" choices is included in the list of variable names and the list of equations. 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"? > 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? 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? -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
