<div dir="ltr">On Fri, May 20, 2016 at 1:30 PM, Hal Murray <span dir="ltr"><<a href="mailto:hmurray@megapathdsl.net" target="_blank">hmurray@megapathdsl.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[pool limit of 100 ms]<br>
<br>
<a href="mailto:esr@thyrsus.com">esr@thyrsus.com</a> said:<br>
> That's weird.  Why would they have a precision requirement *above* RFC5905's<br>
> "A few tens of milliseconds"?  You'd think they'd want it to be below that.<br>
<br>
If you want time in the range of 10s of ms, you need to select the servers you use.  With something like the pool, you are likely to get a server on the other side of the country with associated routing quirks.<br>
<br>
I think the goal of the pool project has always been good-enough rather than great accuracy.  100 seems like a reasonable cutoff point to me.  What did you have in mind?<br>
<br>
Another consideration is that there is only one monitoring station.<br>
<span class=""></span></blockquote><div><br></div><div>From reading their documentation, they monitor the pool candidates and report on their merit.  The availability of the metrics could be better, but they are trying to ensure a minimum.  Their goal is related to human-scale time.  Also, I think their focus is spreading the load.<br><br></div><div>BTW, I was getting within 5ms using generic ublox-7 puck (no PPS) on an old laptop. USB PPS (GR-601W) was reliably under 1ms.<br><br></div><div>Clark<br></div></div></div></div>