> I understand you, and I want us to be good citizens, but reality seems to be > backing us into a corner here. Gary has strongly advised against using > general pool servers. His reasons seem cogent, especially if our Pis are > going to be used, as intended, to *feed* the pool. We don't want our Pis to > create a GIGO loop that indiscriminately boosts the signal of crappy > servers.
> I'd prefer not to use check servers at all and supply only the GPS time > after sanity-filtering it locally. But I've been too busy to follow up on > the discussion of whether they're actually required (I badly want to, but my > mailbox keeps getting flooded...) > Until that issue is resolved, I don't see that I have any alternative but to > default to a fixed set of known-good servers that implicitly hold themselves > forward as public utilities. You going to tell me that a hostname like > 'clock.isc.org' isn't doing that? :-) > I want to put a hold on this part of the discussion until I can reply to > your mail on the requirement(?) for three check servers. I agree it's > important, but I don't see any gain in trying to resolve this issue without > getting the other right first. There are several ideas tangled up here. One branch is which servers to use. Another is why. In this context, the why is pretty simple. The idea is to sanity check the local refclock. There is a long history of time related bugs. They occur all over the place. For example, there was a 13.7 microsecond glitch in GPS a few months ago. It didn't last long. https://www.febo.com/pipermail/time-nuts/2016-January/095692.html Usually, something like this turns into a discussion of how many servers do I need for a simple client (no refclocks) setup. If you use 3 servers, 2 good ones can outvote 1 broken server. If you use 4 servers, you can still kick out a falseticker when one of your servers is not responding. If you have a good refclock, then you don't need great external clocks to get accurate time. The time will come from your refclock. The external servers just need to be good enough for a sanity check. Now for which clocks... > You going to tell me that a hostname like > 'clock.isc.org' isn't doing that? :-) The name is "clock", not "clock-that-anybody-is-free-to-use-and-abuse". Apple has time.apple.com. If you were Apple, setting up NTP servers for your customers, what would you use for a name? Have you seen any hints that those servers are open to the general public? Google has time{1,2,3,4}.google.com Each has both IPv4 and IPv6 addresses. They are stratum 2, but Google has a good internal time setup to support their database activity and Google's network connections are generally good and usually symmetric. I haven't seen any public welcome announcements. I assume they are primarily to support Android phones. They also do leap smearing. Many years ago, the ntp project maintained a list of public NTP servers. It was a good place to look for things like this. There was a page for each server with a rules of engagement section. There were often geographic or organizational restrictions. http://support.ntp.org/bin/view/Servers/WebHome#Browsing_the_Lists Check the last update dates. I think we should set a good example. I admit that's not simple, but wiring names or addresses into a document like this is pretty clearly a bad idea. Even if you are willing to bend the rules, the servers you picked won't work all that well. You picked US centric servers. Don't you expect people in Germany or India or South Africa to read your document? Even within the US, routing can turn a "good" server on the other side of the country into a crappy server. (From Silicon Valley, the NIST servers in Gaithersburg MD are off by 30 ms due to asymmetric routing.) My suggestion would be to use the pool. Not "server 0.pool..." but "pool 0.pool..." There is already logic to kick out dead servers and get new working ones. If it's appropriate, we can tune that section of code, say drop the worst one every day. -------- There is another worm in this can. If your internet link has bufferbloat problems, the servers that are supposed to be checking your refclock might all get shifted far enough that they think the refclock is broken. If you have that problem, you probably don't want to be running a pool server anyway. Users of your system will see the same time warp in the other direction. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
