Set Your Clocks With Pooled NTP Servers

flok writes "Since we all want to have the time correctly set on our servers we all want to synchronize to some ntp-server. Not everyone has such an NTP server available, so that is why www.pool.ntp.org was started. If your server is synced to some discrete timesource like GPS or something like that you can also join the group to help this initiative!"

Comments

Many publicly available time servers

[Visigothe]

There are many publicly available time servers. I don't quite get why this is all that important. When "Public Time Server" is entered in Google, the first hit yields a good resource:

http://www.eecis.udel.edu/~mills/ntp/servers.html

Can anyone enlighten me on why this is special? I couldn't make it out from the site

Re:Many publicly available time servers

[Anonymous Coward]

There are many publicly available time servers. I don't quite get why this is all that important.

It's useful to use the pool as a default address when distributing software, routers, etc., to avoid situations like this: Flawed Routers Flood University of Wisconsin Internet Time Server.

Re:Many publicly available time servers

[rusty0101]

Yep, the protocol is "low bandwidth", then again that does nothing for the utilization bandwidth that the server's experience.

By default, Windows 2k (and beyond) when time service is started all hit Microsoft's time server. Can't think of a better way to burn up Microsoft's bandwidth myself, but such is life.

By default Netgear routers (up until the last six months or so) all attemmpted to get their time reference from the University of Wisconsin't time server. There was a flaw in the software that caused the implementation that caused the devices to pull down time samples repeatedly, and this caused an effective denial of service to the UW connectivity for the location that provided that clock service. (perhaps a fix would have been to alter the dns entry to point back to microsoft's server, though that might have been actionable.)

Additionally just because a time server is available today, does not mean that it will be publically available tomorrow.

Personally I like the option of using Tick and Tock, over using a gps time source, because Tick and Tock have been corrected for cosmic clock drift, while the gps clocks have not been so adjusted.

But that's just me. Use your own adjusted time source.

-Rusty

Re:time.apple.com

[nocomment]

Maybe redundant maybe not but I use tick.usno.navy.mil and tock.usno.navy.mil. The US Navy is the official time keepers of the military and therefore all things are sync'd with them and in turn these public servers. That includes GPS. Doesn't get much more accurate than that.

As an aside I don't see what the big deal is. The public pool has been around for how long? It's been the default in Mandrake since 9.0-ish(?).

Use .pool.ntp.org instead...

[SchnauzerGuy]

As pool.ntp.org will assign you timeservers from all over the world, time quality will not be ideal. You get a bit better result if you use the continental zones (europe, north-america, oceania and asia.pool.ntp.org currently exist), and even better time if you use the country zone (like ch.pool.ntp.org in Switzerland). Note, however, that the country zone might not exist for your country, or might contain only one or two timeservers. If you know timeservers that are really close to you (measured by network distance, with traceroute or ping), time probably will be even better.

You will definitely want to use either the continent or country code versions of pool.ntp.org, otherwise you might end up sychronizing with a very distant timeserver, resulting in more NTP jitter and less accurate time.

For example, us.pool.ntp.org or north-america.pool.ntp.org would be a good choice for people in the United States.

Re:Accuracy?

[mgarraha]

If you use multiple servers, ntpd will ignore the outliers and sync to the one with the smallest error bar. See RFC 1305 for details.

Re:time.apple.com

[SpaceLifeForm]

Exactly why this pool makes sense. You want to make it easy for everyone to have at least decent accuracy but also to take the load off of the tier1 servers. Once more machines join in, it will make it much easier to tune to your requirements. Your normally could find more info here, but apparently there exists a discontinuity in the time dimension.

Re:A small piece of experience

[alphaseven]

Found this article from a few years ago:

But repeated tests of the Windows XP Internet Time utility produced a variety of unharmonious results. Compared with the NIST's atomic clock, Microsoft was repeatedly off by as much as nine minutes.

Maybe that was the problem. Microsoft has since fixed it.

Re:Accuracy vs Precision

[mgarraha]

I would try something like this for a local server, e.g. 192.168.1.42:

server us.pool.ntp.org
server us.pool.ntp.org
server us.pool.ntp.org
driftfile /etc/ntp/drift
restrict default nomodify notrap noquery
restrict 127.0.0.1
restrict 192.168.0.0 mask 255.255.0.0 notrust nomodify notrap

Everything else would be a client, like this:

server 192.168.1.42
driftfile /etc/ntp/drift
restrict default ignore
restrict 127.0.0.1
restrict 192.168.1.42 nomodify notrap noquery

Re:NIST?

[arcade]

Uhm. It's a stratum 1 server. That is what is wrong. You should never abuse stratum 1 servers unless you're a selfish bastard.

Unless you want time to get really unreliable, you should use stratum 2 or stratum 3 servers, as the stratum 1 servers cannot keep up if everybody uses them.

Personally I sync my local stratum 3 timeserver against two stratum two servers -- and about 50 computers sync against my one stratum 3 server.

Re:time.apple.com

[nocomment]

You are not special. You do not get to be an exception to the rules.

I'm not, I'm following them. You can too! :-)

Re:time.apple.com

[nthomas]

I remember hearing a few years ago that the folks who ran tick and tock asked that only second-tier time servers sync to them, and that all the "leaf nodes" sync to a second-tier server.

I heard something similar a while back, but in this case, the guilty parties were sticking ntpdate(1) into a cronjob and pointing it at the time servers, having it run at the top of every hour. =-(

In response, I posted the following notice. I'm reproducing it here (without updates or corrections), in the hopes that may be helpful:

To: debian-user@lists.debian.org
Subject: ntpdate from cron -- DON'T DO THAT!
From: "N. Thomas" <nthomas@cise.ufl.edu>
Date: Sat, 21 Dec 2002 18:51:24 -0500

Contrary to what you may have heard, ntpdate does not keep your system clock synced. Also ignore the foolish recommendations to run ntpdate from a cron job.

ntpdate works like date(1), but it sets your clock's time to that of an ntp server (or servers) instead of having it specified by you.

If you want to keep your clock in sync use ntpd -- that's what it was designed for. It uses many sophisticated algorithms and statistical methods to accomplish this. After some time, it can even figure out how "bad" your system clock is (i.e. its drift) and compensate for it, even if your network connection goes out.

Unfortunately, some people, instead of taking the time to read the ntp documentation and writing a proper ntp.conf file, took the easy route and started running ntpdate from cron.

This caused two problems, firstly it did not keep very good time: immediately after you called ntpdate, your clock would begin to drift again. And more importantly, every hour or so, the ntp servers were being affected by a "thunderclap" effect, the result of everybody putting:

0 * * * * /usr/local/bin/ntpdate

or something similar into their crontab files. The ntp daemon does not do this as it randomizes the time it waits between queries.

For this reason, Dr. Mills (ntp author) has deprecated ntpdate, and indeed, he will be removing it completely from a future release.

In addition to helping those without a handy ntp server, pool.ntp.org actually helps to minimize "wear and tear" on the popular NTP servers. Congratulations are in order to Mr. von Bidder for coming up with this great system.

Thomas