NIST NTP servers

[laszlo at heliacal.net (Laszlo Hanyecz)]

On 2016-05-10 15:36, Mike wrote:
> On 5/10/2016 11:22 AM, Leo Bicknell wrote:
>> In a message written on Mon, May 09, 2016 at 11:01:23PM -0400, b f wrote:
>>> In search of stable, disparate stratum 1 NTP sources.
>> http://wpollock.com/AUnix2/NTPstratum1PublicServers.htm
>>
>>> We tried using ?time.nist.gov? which returns varying round-robin addresses
>>> (as the link says), but Cisco IOS resolved the FQDN and embedded the
>>> numeric address in the ?ntp server? config statement.
>> Depending on your hardware platform your Cisco Router is likely not
>> a great NTP server.  IOS is not designed for hyper-accuracy.
>>
>>> After letting the new server config go through a few days of update cycles,
>>> the drift, offset and reachability stats are not anywhere as good as what
>>> the stats for the Navy time server are - 192.5.41.41 / tock.usno.navy.mil.
>> The correct answer here is to run multiple NTP servers in your
>> network.  ...
>> [snip]
>
> I think the correct answer here starts with a question --- what level of
> time accuracy is required for the local NTP server(s)? Which then begs
> the question, what level of accuracy is needed for the clients?
>
> A shop with a client need for nanosecond accuracy begs for an entirely
> different solution set than a shop where a millisecond of accuracy is
> needed on the clients, and still a different solution set that a shop
> where "a few milliseconds either way" is quite OK.
>
>
>
>
You can get pretty nutty with this, and it's fun to do, but regular NTP 
over the internet is good enough for millisecond accuracy.  A default 
install with pool servers is pretty good.  A custom config with a local 
NTP server (with less, possibly more symmetric network latency) is a 
little better, but for common sysadmin needs like cron jobs and log 
correlation, you likely won't notice a difference.  I would worry more 
about having that config distributed correctly and monitoring all your 
servers to make sure their NTP is healthy, rather than worrying about 
the source of your NTP sync.  The pool servers are fine, and NTP is good 
at deciding when they're acting up.  The computer running NTP doesn't 
have to be anything special, but beware of VMs - depending on the 
virtualization type and the guest OS, you may not even be able to get 
NTP to engage because of the clock instability.  Chrony might work 
better for VMs.  For a linux NTP server, I prefer modern Intel CPUs with 
invariant tsc - linux will use it as a clocksource (cat 
/sys/devices/system/clocksource/clocksource0/current_clocksource
) .  A Raspberry Pi or something in between also works equally well if 
you're going to be syncing this over a jittery shared network anyway.  I 
would suggest having more than one server, in different locations if you 
can, and if you're able to supplement with pool servers, add those too.  
The most likely failure mode you're going to have is that it doesn't 
work at all because it's not running, it can't correct the local clock 
because of excess instability, or you lost all network connections.  
Worrying about whether you have 4 or 8 servers is kind of moot in any of 
those (much more likely) faults.

-Laszlo