<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 24 Nov 2017, at 09:20, Hal Murray <<a href="mailto:hmurray@megapathdsl.net" class="">hmurray@megapathdsl.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><a href="mailto:neil.davies@pnsol.com" class="">neil.davies@pnsol.com</a> said:<br class=""><blockquote type="cite" class="">There are a few more issues - the relative drift between the two clocks<br class="">can be as high as 200ppm, though typically 50-75ppm is what we observe, but<br class="">this drift is monotonic.<br class=""></blockquote><br class="">200 ppm seems pretty high, but not off scale. If ntpd is running and not <br class="">getting confused by long queuing delays, it should correct the drift to well <br class="">under 1 ppm. If you turn on loopstats, you can graph it.<br class=""></div></div></blockquote><div><br class=""></div><div>I’m saying that is the maximum rate of drift between two clocks even</div><div>when they are under NTP control. As you say below the clock rates</div><div>are not completely stable they are temperature dependent.</div><div>When we did this with the guys at CERN we could</div><div>correlate the results with the workload (see below for references).</div><div><br class=""></div><div>We’ve got ~1M experiments using this approach across various networks, </div><div>the numbers are what we are seeing in practice. </div><div><br class=""></div><div>The caveat is that, after a while (i.e several 100s) the clock drift can make</div><div>a significant difference (i.e a few ms) in the one-way delay estimation. </div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">If you are blasting the network and adding long queuing delays, ntpd can <br class="">easily get confused.<br class=""><br class="">There is another quirk to keep in mind. The temperature coefficient of the <br class="">crystal is ballpark of 1 ppm per C. Things can change significantly if an <br class="">idle system starts flinging lots of bits around.<br class=""><br class=""><br class=""><blockquote type="cite" class="">Also NTP can make changes at one (or both) ends - they show up as distinct<br class="">direction changes in the drift. <br class=""></blockquote><br class="">I'm not sure what you mean by "direction change". I'd expect a graph of the <br class="">time offset vs time to be linear and the slope would have a sharp change if <br class="">ntpd changed it's "drift" correction and/or maybe a rounded bend as a system <br class="">warmed up.<br class=""></div></div></blockquote><div><br class=""></div>Don’t forget you are measuring the difference in the rates between two NTP clocks,</div><div>hence the change when one of the NTP systems decides to change the drift rate</div><div>the relative rate can change direction.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class=""><br class="">----------<br class=""><br class="">Are you happy with whatever you are doing? Should we try to set things up <br class="">so ntpd works well enough? How close would you like the times to be? …<br class=""><br class=""></div></div></blockquote><br class="">Yep, we’re very happy - we don’t care that there is a linear clock drift (we</div><div>can correct for that) and the step changes are infrequent and can be eliminated</div><div>from the long term analysis.</div><div><br class=""></div><div>You might find §4.4 (esp §4.4.5) and §5.6 in </div><div><a href="https://cds.cern.ch/record/1504817/files/CERN-THESIS-2013-004.pdf" class="">https://cds.cern.ch/record/1504817/files/CERN-THESIS-2013-004.pdf</a> </div><div>interesting. It illustrates these sort of issues. </div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><br class=""><br class="">-- <br class="">These are my opinions. I hate spam.<br class=""><br class=""><br class=""><br class=""></div></div></blockquote></div><br class=""></body></html>