On Dec 6, 2014, at 8:33 AM, William Unruh <un...@invalid.ca> wrote: > On 2014-12-06, Charles Swiger <cswi...@mac.com> wrote: >> >>> On Dec 5, 2014, at 8:39 PM, William Unruh <un...@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: >> >> http://chrony.tuxfamily.org/manual.html#How-can-I-improve-the-accuracy-of-the-system-clock-with-NTP-sources_003f > > 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. > 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. 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? >>>> 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 > rate. 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. (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. ...and skip the rest as being addressed above. Regards, -- -Chuck _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
