Re: [nznog] ntp2.ntp.net.nz failure

On Sat, August 2, 2014 6:21 pm, Jay Daley wrote:

On 2/08/2014, at 3:41 pm, Nathan Ward wrote:

...

I agree re. s/p - the meaning here isn’t 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 don’t 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 Mark’s use case to work, while not significantly impacting accuracy for those just using all 3 ntp.net.nz servers. I haven’t 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 s1.ntp.net.nz.

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