[time-nuts] Re: List Opinion/Suggestion(s)

[Hal Murray]

kb8tq at n1k.org said:
> I would strongly suggest that with NTP ���more is better���. Three reference
> devices is about the minimum. Five is a good target to aim for.

I think it's more complicated than that.  Quality over quantity.

Using more servers does give you a better chance at getting a good one, but 
that's not the usual reason for discussing how many servers to use.

If you are using 3 servers, 2 can outvote a bogus one.  (Mills calls good 
servers truechimers and bogus one falsetickers.)  If one of the 3 servers is 
down, that doesn't work any more.  Add more servers and you can work out what 
happens if 2 are down or 2 are bogus.

--------

After an exchange of NTP packets, the client has 4 time stamps:
  the time when the request left the client
  the time when it arrived at the server
  the time when the response left the server
  the time when it arrived back at the client
2 of those times are using the client's clock and 2 are using the server's 
clock.

There are 3 unknowns: the transit time in each direction and the offset 
between client and server clocks.  The 4 timestamps give you 2 equations.

ntpd gets a 3rd equation by assuming that the transit times are equal - 
symmetric routing.  That lets you solve for the clock offset.

If you have a good local clock, you can assume the clock offset is 0 and solve 
for the transit times.

----------

> If you have a symmetric delay on your connection to the internet ( delay up
> and delay down are the same) then indeed net based devices can do quite
> well. It���s a rare basement lab that has this sort of connection.

Yup.  But lets look at some numbers.  Assume the downlink is super fast so we 
can ignore that delay.  So all the delay on the uplink turns into assymetry.  
Assume an NTP packet is 100 bytes.  Assume a byte is 10 bits.  That's 1000 
bits.  If your uplink is a megabit, that is 1 ms.

Compare that to network routing delays.

In general, the farther away (hops, not miles) a server is the more likely it 
is that the request and reply will take different physical routes.  If the 
physical distance (miles) is long there is a good chance that different 
physical routes will have different lengths and hence different delays even if 
the hop counts each way are the same.

I'm in Silicon Valley.  NIST has servers in 3 locations in the Boulder CO 
area.  The servers at NIST and WWV appear to be off by 6 or 7 ms.  The servers 
at U of Colorado are off by 5 ms in the other direction.

The other source of network asymmetry is queuing delays.  This often gets ugly 
due to bufferbloat.  That usually happens on the last mile link.  My old slow 
DSL line could get delays over 3 seconds. ;)  It was easy to spot long 
downloads by looking at the NTP data.

You can make a wedge diagram.  For each packet pair, plot the average transit 
time on the X axis and the clock offset assuming symmetry on the Y axis.  You 
should get a wedge pointing to the left.  The points along the edges of the 
wedge are routing delays in one direction when there were no delays in the 
other direction.  Points in the middle of the wedge  encountered routing 
delays in both directions.

Note that routing delays change, both short term (hours) as links go up/down 
and long term (months, years) as people/companies move or change ISPs and 
anybody in the path adds/retires a link.  Just because it looks good now 
doesn't mean it will be good in an hour, or tomorrow, or next year.

----------

That's all a longwinded way of saying that finding good local servers is 
likely to work better than just adding more servers.

----------

Geek note:  If you are running a NTP server (without a local refclock) the 
asymmetry on your local link cancels out.  Your clock will be off a bit due to 
the asymmetry on packets used by your NTP client.  That will cancel out the 
asymmetry when your ntpd is acting as a server.


-- 
These are my opinions.  I hate spam.