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