nanog mailing list archives
Re: NIST NTP servers
From: Laszlo Hanyecz <laszlo () heliacal net>
Date: Tue, 10 May 2016 16:08:57 +0000
On 2016-05-10 15:36, Mike wrote:
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.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.htmWe 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.
-Laszlo
Current thread:
- RE: NIST NTP servers, (continued)
- RE: NIST NTP servers John Souvestre (May 12)
- Re: NIST NTP servers Chris Adams (May 12)
- RE: NIST NTP servers John Souvestre (May 12)
- RE: NIST NTP servers Chuck Church (May 11)
- Re: NIST NTP servers George Herbert (May 12)
- RE: NIST NTP servers Allan Liska (May 11)
- RE: NIST NTP servers Chuck Church (May 10)
- Re: NIST NTP servers Mike (May 10)
- Re: NIST NTP servers Laszlo Hanyecz (May 10)
- Re: NIST NTP servers Harlan Stenn (May 10)
- Re: NIST NTP servers Jared Mauch (May 10)
- Re: NIST NTP servers Gary E. Miller (May 10)
- Re: NIST NTP servers Jared Mauch (May 10)
- Re: NIST NTP servers Mel Beckman (May 10)
- Re: NIST NTP servers Chris Adams (May 10)
- Re: NIST NTP servers Mel Beckman (May 10)
- Re: NIST NTP servers Roland Dobbins (May 10)
- Re: NIST NTP servers Joe Klein (May 10)
- Re: NIST NTP servers Eric Kuhnke (May 10)