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

I for one...

[roseblood]

welcome our well timed overlords.

time.apple.com

[Twirlip of the Mists]

Not everyone has such an NTP server available

Yeah, you do. Just use time.apple.com.

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(?).

Re:time.apple.com

[Twirlip of the Mists]

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. That's why I don't use tick or tock any more.

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: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

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:Many publicly available time servers

[cgenman]

(perhaps a fix would have been to alter the dns entry to point back to microsoft's server, though that might have been actionable.)

Actually, as another flaw in Netgear's hardware, the IP address was hard-coded. No such DNS trickery would help.

Re:Many publicly available time servers

[Anonymous Coward]

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

I didn't take me much to figure it out. Public time servers have always been a pain. Some are up and down. Many require you send a nice e-mail before using them. This is much easier. You just add "server pool.ntp.org" three times. Each time it gets the IP of a different server, so you have redundancy and easy configuration for free.

I wish someone had thought of that before. Now, the important thing, is someone monitoring the pool and tossing out bad servers? It says there was a discussion on the e-mail list, but I've got better things to do now.

Re:Many publicly available time servers

[devphil]

You find a computer-based application that I use which misbehaves in the presence of cosmic clock drift, and then I'll care about GPS correction. :-) Until then, what's the point?

Firewalled

[BrookHarty]

Anyone know if there is an http/proxied enabled ntp program? Cant find anything for a firewalled machine, been using ssh tunnel. (kinda on topic)

NIST?

[AcornWeb]

Uh, what is wrong with time.nist.gov ?

Re:NIST?

[mgarraha]

Unless you are running a stratum 2 server for hundreds of clients, it's polite to stay off the stratum 1 servers. Two or three us.pool.ntp.org servers do almost as well. My ISP's routers are stratum 3 NTP servers, and I use one of those.

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:NIST?

[metamatic]

Well, if NIST don't want random people using their stratum-1 servers, they shouldn't be inviting and instructing the entire world to use their stratum-1 servers, should they?

Re:NIST?

[MasTRE]

> Unless you want time to get really unreliable

Ah, words only a true geek could utter ;) And get..

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:Use .pool.ntp.org instead...

[MasTRE]

Would have been a good idea if the web page actually listed all the exact host names and not just briefly mentioned their existance as an afterthought.

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.

Accuracy vs Precision

[Lord Bitman]

why would anyone want accurate time based on many differing servers accross the world? On a network, the key is to have precise time. That is, the exact same not-neccessarily-correct time on every single computer on the network.
I have never managed to get this suitably set up using NTP. Anyone have success with this and willing to explain?

Re:Accuracy vs Precision

[wizbit]

On a network, the key is to have precise time. That is, the exact same not-neccessarily-correct time on every single computer on the network.

NTP seeks to find coordinated universal time (UTC), that is, the "one true time" as a basis for every local time on the planet. NTP is composed of several stratums of time servers which try to determine UTC using a complex series of algorithms to measure "drift" and deviation from UTC between servers and stratums.

If you need to set your wristwatch, you look at a wall clock for reference, right? If you have a network of wall clocks across 24 time zones, you choose one as a reference and set the rest accordingly. That reference clock might be an atomic clock or a swatch watch; it doesn't particularly matter where the timekeeper is located, only that your relative distance and time differential is measured precisely. In UTC, this is UT1, the 0-median (like Greenwich Mean Time - the time at 0 longitude).

ntpdate and ntpq -pn will give you an idea of the drag between your clock and the timeserver you are connected to - theoretically, when one hour has elapsed on one clock, all clocks should should strike the hour at the same time. Since this is not possible to an infinite degree of precision, the "drag" is the amount of time it takes your clock to "catch up" and strike the hour, whether it's early or late for the period, typically the hour. Extend that out to a year, or more appropriately, several years, and you'll find even clusters of atomic clocks that strike midnight, January 1st in a leap year several nanoseconds ahead of the astronomical date change. Every year, several "leap seconds" are added to account for the differential.

Anyway, the idea is to get your server to acquire, yes, a "not-necessarily-correct time" from a variety of sources and determine the most likely time for your geographic location, usually within a few nanoseconds, and then broadcast that time for every machine on your network to syndicate. The result is not absolute perfection, but a logical use of network resources to acquire a mostly-correct time.

You'd want to set up an NTP server (maybe several) that poll stratum-2 or -3 servers for the time, and ntpd to syndicate the time for the rest of your network. Win XP, Mac OS X, etc. machines can grab the correct time every reboot, or every network logon, or whatever you prefer. The result will invariably result in a slight adjustment every time a client "re-ups" for the right time, but it should be more than sufficient for the accurate synchornization of network-wide tasks.

If you're interested in best-practice scenerios with NTP, you should really check out www.ntp.org.

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:A small piece of experience

[mgarraha]

time.windows.com and clock.redhat.com are within a few milliseconds of each other. It sounds like your laptop wasn't in sync. If your /etc/ntp.conf has a line saying "restrict default ignore" then you need to add another "restrict" line for the server(s) you want to use.

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.

Cosmic clock drift

[Chemisor]

> because Tick and Tock have been corrected for
> cosmic clock drift, while the gps clocks have not been so adjusted.

I am sure you are reaping great benefits from knowing what time it is to sixteen decimal places.