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
