On Sat, August 2, 2014 6:21 pm, Jay Daley wrote:
On 2/08/2014, at 3:41 pm, Nathan Ward <nznog(a)daork.net> wrote:
I agree re. s/p - the meaning here isnt
immediately obvious from the
name, I have to look them up when I want to figure out which to use. I
note that both s2 and p2 point to ntp3 - is that intentional, or should
only s2 point to ntp3? Out of interest, what do s/p actually stand for?
Perhaps pool.ntp.net.nz" could have A records for the current working
servers, and ask that people with clients that dont support more than
one peer/want to do one-shot sync etc. use that.
I thought about that originally but I was concerned about being added to
the global pool list. We'll look at this again though.
Looking at the AUP I always presumed that the differentiation between
s2/3/4 and p1/2/3 was to allow future differentiation between 'classes' of
client. This doesn't seem like a bad idea, even if (currently) they wind
up going to the same place(s).
Another thought I had since last night was that
maybe ntp2 could be
pointed at a stratum 3 or higher server in the interim, to allow Marks
use case to work, while not significantly impacting accuracy for those
just using all 3 ntp.net.nz servers. I havent thought through all the
complexities of this, but, it seems like an option. It would be
interesting to understand how many people use ntp2 and not the other
servers, I would imagine most people with single-peer clients would use
We should have delivery date early next week and if it's too far off then
we'll discuss that.
I've never pointed at 'ntp2' as that's not one of the hosts described in
the AUP and the Architecture description asks for folks to use pX and sX
and not ntpX.
As for which NTP server people use, where they can only configure a single
NTP server I would usually traceroute to each one and pick the one with
the shortest or least-latency path. In my case NTP2 is 'close to home'
and so I would use p2 or s2 depending on the use case - but that won't be
the same for everyone.
I do agree that a generic 'pool' for that use case sounds like a great
idea, letting p2/s2 be used for machines that can talk to multiple
timeservers for greater accuracy.