On Sat, Feb 21, 2015 at 1:57 AM, William Unruh <[email protected]> wrote: > > On 2015-02-21, Paul <[email protected]> wrote: > > On Fri, Feb 20, 2015 at 3:23 PM, William Unruh <[email protected]> wrote: > > > >> ??? how do assume that the chrony docs do not tell the truth? > ^ you >
Okay, I'll assume (or pretend) that you mean "Why do I assume the Chrony documentation is in error" and the answer is believing you. This is why I suggest you stop paraphrasing and stop asking for paraphrasing. Provide references to sources and stop doing original research. You said: "Lichvar did some tests with PPS and found that chrony disciplined the clock much better than did ntpd (factors of over 10)" and since NTPd can get to sub-microsecond your statement means Chrony is getting at least O(10) nanoseconds. The Chrony document says: "With a good reference clock the accuracy can reach one microsecond." So one of you is wrong. Except it turns out you're both wrong. Miroslav Lichvar says "If the clock is stable enough, they can perform similarly." so the Chrony doc understates the performance and you overstate it considering the current/recent state of the art. And now some original research: I switched my most challenging *client* (stratum 2 on a powerline network) from NTPd to Ntimed-client to Chrony. NTPd had excursions in O(10) to O(100) microseconds, Ntimed-client managed O(1) to O(10) microseconds and Chrony managed a reasonably consistent 1 millisecond offset. I used stock conf files except Ntimed-client doesn't use one. So points to Chrony for being more consistent. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
