[ntp:questions] Red Hat vote for chrony
unruh at invalid.ca
Mon Dec 8 03:27:15 UTC 2014
On 2014-12-07, Charles Swiger <cswiger at mac.com> wrote:
> On Dec 6, 2014, at 8:33 AM, William Unruh <unruh at invalid.ca> wrote:
>> On 2014-12-06, Charles Swiger <cswiger at mac.com> wrote:
>>>> On Dec 5, 2014, at 8:39 PM, William Unruh <unruh at invalid.ca> wrote:
> [ ... ]
>>>>> Just like your claim whether the chrony docs recommend using maxpoll=4
>>>>> across the network to a LAN timesource or not was wrong?
>>>> I have given you the quotes from the chrony docs. Where do you get your
>>>> statement from?
>>> The chrony docs, section 5.3.4:
>> OK, lets quote the whole section
> [ ...section snipped, as you found what I linked to and even quoted before... ]
>> Note the caveates : server located on the same lan. In fact more
>> frequent polling IS better especially when one uses the a system with
>> memory-- ie where the system uses the offsets measured for the last 64
>> times to figure out what the best time now is.
> Yes, so chrony recommends using maxpoll=4 to the LAN, and not only to local refclocks.
No, read the chrony docs. the default is maxpoll 10 minpoll 5.
That the faq as an example uses 2 and 4 is I agree stupid. It is faq. I
have no idea who wrote it.
>> But, compare this with the actual documentation for chrony, not this
>> faq which I quoted, and you erased. (Minpoll 5 maxpoll 10)
> Dude, give it a rest. You've just acknowledged that the chrony docs at the URL
> ending with "manual.html" directly above recommend using maxpoll=4 to the LAN.
No, the FAQ has that as an example.
> Yes, the default values compiled into chrony of minpoll=5 maxpoll=10 are nearly
> the same as what ntpd uses, which is polite when talking to the NTP pool or
> other WAN sources that you haven't made prior arrangements with.
> Can we skip the pendantry involved between "default" and "recommended",
> especially when you seem to prefer the recommended faster polling yourself?
Especially when the document you quote does not use the word
"recommended" It uses the word "example".
>>>>> Just like your claim about whether ntpd cares about figuring out the local
>>>>> clock frequency or whether it only chases the offset was wrong?
>>>> ntpd does not care about figuring out the local clock frequency.
>>> You keep repeating this assertion when it is quite obviously wrong.
>>> Above, you've acknowledged that ntp.drift contains the (frequency) offset
>>> for the clock. That's the single most important piece of data to have
>>> around even if the machine loses network connectivity with other timeservers,
>>> or ntpd is restarted, or the machine itself is rebooted.
>> It is ONLY used when the ntpd is started/restarted.
>> If it makes you feel happy, yes ntpd does know about the current drift
> Try not to confuse making me happy with being able to state the truth,
> be honestly mistaken about a point but also acknowledge it once corrected,
> or chosing to be wilfully dishonest.
> Nothing personal: everyone faces such a choice....
>> It knows nothing about the past drift rate. That is what I call
>> memory. And in normal operation, it does not even know about the current
>> drift rate-- it is the operating system that does that. All ntpd does is
>> to change the current drift rate to try to minimize the offset.
>> IF the operating system is incapable of changing the clock rate, ntpd
>> tries to do it for the operating system. Every second it resets the
>> clock to take into account the error in the rate of the clock. In this
>> case, ntpd remembers the current drift rate. But only the current drift
>> rate. Again, it has no memory of the past.
> When ntpd has been up for a while using default maxpoll=10, how many past polls
> are available (per timesource), and what interval of time does that represent?
> You answered that below, in fact:
> "Note that before it actually runs, it does remember the past 8 offsets AND delays,"
> ...which turns into 8 * 1024 seconds ~= 2.27 hours. If we cannot manage to
> agree that this data is kept in memory by ntpd, then further discussion of what
> ntpd might or might not do in "discarding 7 out of 8 polls" and so forth is
> completely moot.
It is not used to set the clock. NOte that I will agree that ntpd also
writes to a file the measurements in the logs. So what? It is not used
> (Starting from a false premise proves nothing about the following conclusion.)
>> Since you keep wanting to say I am wrong, why do you not tell us how
>> ntpd works in your understanding?
> Let me provide three responses:
> 1) I'd prefer you to say things which are accurate as to fact rather than arguing.
> 2) If you believe a statement I've made to be mistaken, feel free to point it out.
> 3) I'd rather test and submit patches than try to educate someone who doesn't want to learn.
Thought so. I interpret 1 as "I don't know", 2 as "the fewer statements
I make the less others can point out". For 3) how many patches and to
what have you submitted?
> ...and skip the rest as being addressed above.
More information about the questions