[Ntp] Re: NTP speed of synchronization question

[Hal Murray <[e-mail]>]

[e-mail] said:
> Assuming typical high-end routers and their implementation of NTP:

> 1. Is there any reasonw why we should NOT be able to achieve
> synchronization of less than 5 msec ? 

> 2. Assuming synchronization only across some WAN connection...

I know roughly nothing about high-end routers.

The previous answers looked good.  Here is my 2 cents worth.


You need to ask the router venders what sort of NTP software they are 
running.  There is a lot of crapware out there claiming to be NTP.  It 
wouldn't surprise me if some vendor was still using their old 
works-well-enough software.  If it ain't broke, don't fix it.

If you want to get in the 5 ms range using servers on the WAN, you need to 
pick your servers carefully.  The server needs to be accurate and the 
routing needs to be symmetric and NTP traffic needs to not be filtered.

I'm in Silicon Valley with an AT&T fiber.  I have a good GPS setup to use 
as a reference.


>From here, the time from NIST servers in Boulder and Fort Colins is off by 
about 6 ms.  The round trip time is normally 45 ms.  It ccasionally drops 
to 33 ms for a while.  When that happens, the time is accurate.  The 
normal case is classic asymmetric routing.  Those servers look good from a 
cloud server in San Francisco -- 28 ms round trip.


Various ISPs, routers, and whatevers filter NTP packets.  That's leftover 
from a giant DDoS attack many years ago that used NTP's monlist option.  
That filtering is rarely documented.  It's a pain to debug and close to 
impossible for mere mortals to get fixed.

Google, Facebook, and Cloudflare all offer public NTP servers.  I think 
they all use anycast so you get the nearest server.  From here, I can't 
get to 1 of Google's IPv6 servers.  I can't get to any of Facebook's IPv4 
servers.  They were working several days ago.  I can't get to one of 
Cloudflare's IPv6 servers -- the TCP connection for NTS-KE times out.  All 
those missing servers work fine from San Francisco.


You can't tell how far off a system's clock is unless you have a good 
local clock to use as a reference.  You can't just ask the system.  If it 
knew it was off it would fix it.  With asymmetric routing, it will think 
it is good but will be off by half the difference in transit times.


What happens if the time is off a bit, say 10 ms?  How about 100 ms?

I suspect that even with a good setup, the clock will occasionally do 
somethng strange.  More often if you don't have nearby good servers or 
when you have a flakey link.  Will that just screwup the local system or 
explode and take down the whole net?


Odds and ends:

Do you know about bufferbloat?  To NTP, that looks like asymmetric 
routing.  How big can the queues get on the path from your router to/from 
the NTP servers you are using?

Will the NTP software get a CPU when it needs it?  (Or will the CPUs 
sometimes be busy doing more important things like routing packets?)

Do you know about leap seconds?  Leap smearing?

Do you have a database using time stamps for UIDs?  (aka something that 
will panic if time goes backwards)

Are you using time for security?  Basic NTP is easy to spoof with a MITM 
attack.  Servers supporting NTS are harder to find.


-- 
These are my opinions.  I hate spam.