On 2014-12-07, Charles Swiger <cswi...@mac.com> wrote: > 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.
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 >> 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. 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 by ntpd. > > (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. > > Regards, _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
