[aklug] Re: How NTP Works

From: Arthur Corliss <acorliss@nevaeh-linux.org>
Date: Tue Dec 07 2010 - 15:36:10 AKST

On Mon, 6 Dec 2010, Christopher Howard wrote:

> This will tell you the NTP "stratum" of your system. The closer you are to 1, the better, because those are the official sources of time.

FYI: the stratum hierarchy exists for a reason, and unless you need extreme
accuracy (which almost no one here does) *no one* here should be running ntp
clients against anything higher than stratum 2 servers. Every stratum only
adds 1/2 - 100ms of inaccuracy, so you'd have to be to be around stratum 10
before you might be inaccurate by more than one second.

Why do I bring this up? Those of us who run NTP servers know that little
things can do a lot of damage to your NTP servers' accuracy. Things like
excessive CPU loads, hardware interrupts, etc. If everyone here piles onto
a stratum 1 server you're doing a disservice to the hierarchy in general
because you're generating interrupts which make it harder to keep the
server's accuracy. In addition, internal drift calculations become
increasingly more ineffective unless the traffic loads are stable. For this
reason you'll note that there's a lot of low stratum servers whose
accuracy and reliability are worse tha some higher stratum servers.

Keep the load down on the lower stratum servers and pick an appropriate
place in the hierarchy. If your ISP provides a public NTP server, then for
God's sake use it. If millisecond accuracy is that big a deal then you
should really be setting up your own stratum one server by tying into a GPS
system or cesium clock.

One other note: there are situations where ntpdate is hugely preferrential
over ntpd. I made the mistake once of running ntpd on a software routers in
a VRRP config, with the routers acting as NTP peers. Given the the
massively different hardware interrupt activity between the two servers,
plus the inconsistent network loads in general, both servers gradually
drifted out of sync with the lower stratums without knowing it (they thought
they were in sync, but because of highly flawed drift calculations they were
actually significantly off. Bad enough to cause problems with the five
minute permissiveness of kerberos, in fact). At one point it even caused a
problem with VRRP. The only good solution was to run ntpdate hourly, at a
minimum.

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Tue Dec 7 15:36:20 2010

This archive was generated by hypermail 2.1.8 : Tue Dec 07 2010 - 15:36:20 AKST