HOWTO - using other servers

[Hal Murray]

> 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.