Why use NTP?

Time usually just advances. If you have communicating programs running on different computers, time still should even advance if you switch from one computer to another. Obviously if one system is ahead of the others, the others are behind that particular one. From the perspective of an external observer, switching between these systems would cause time to jump forward and back, a non-desirable effect.

As a consequence, isolated networks may run their own wrong time, but as soon as you connect to the Internet, effects will be visible. Just imagine some EMail message arrived five minutes before it was sent, and there even was a reply two minutes before the message was sent.

Even on a single computer some applications have trouble when the time jumps backwards. For example, database systems using transactions and crash recovery like to know the time of the last good state.

Therefore, air traffic control was one of the first applications for NTP.

Basic guidelines

NTP is a service typically running quietly in the background. When servers are chosen they will typically remain in the
configuration "forever". If the client traffic causes trouble for the server it is extremely difficult to mitigate if not carefully
planned for in advance.

You must get approval from the server operator before you
hardcode any IP addresses or hostnames. This is easy to get if your own
organization runs the NTP servers you are planning to use. In most other cases
you will not get it.

Do not use the standard pool.ntp.org names as a default configuration in your system. The NTP Pool can offer services for
you, but it must be setup in advance (see below).

Typically the best solution is for your organization to setup your own cluster of NTP servers, for example ntp1.example.com, ntp2.example.com and ntp3.example.com and use those as the default in your configuration.

What the NTP Pool can offer

The NTP Pool Project was started in 2003 as a response to the rapidly increasing resource consumption
at the popular NTP servers and the problem of these servers then closing their operations. Today it has grown to be central to the operation of millions of systems around the world.

Rather than establish and maintain your own cluster of NTP servers or negotiate with individual server operators to use their server, you can use the NTP Pool.

Get your vendor zone

To allow you to use the pool as the default time service in your
application, we will set you up with special hostnames, for example
0.vendor.pool.ntp.org, 1.vendor.pool.ntp.org,
2.vendor.pool.ntp.org and 3.vendor.pool.ntp.org.

You must absolutely not use the default pool.ntp.org zone names as the default configuration in your application or appliance.

Pool Capacity

The pool is currently keeping the time of an estimated 5-15 million systems accurate.

With our technology and expertise we can vastly expand the number of supported systems with relatively modest contributions.

Implementation specifics

You can choose either to implement a full ntpd server or a simpler SNTP implementation.
A few more pointers and ground-rules:

Only use the pool.ntp.org hostnames designated to you (typically {0,1,2,3}.{vendor}.pool.ntp.org)

Do implement handling of the "KoD" response

Don't send excessively frequent queries. Reasonable query intervals are typically from once or twice a day to a 4-5 times an hour depending on the application. Really consider how often the device will need "fresh time". A standard ntpd or openntpd server works, too.

Do have your devices query the NTP servers at random times of the day. For example every 43200 seconds since boot is good, at midnight every day is bad.

We can refer you to consultants with vast expertise in the NTP protocol and time-keeping applications who can help. Just email Ask Bjørn Hansen at ask@develooper.com.

Open source projects

Open Source projects are of course particularly welcome to use the pool in their default setup, but we ask that you get a vendor zone when using the pool as a default configuration.

Vendor FAQ

Most questions should be answered elsewhere on the page. Here are some that didn't fit in above.

Why use special hostnames for vendors?

The special hostnames allows us some control of the traffic so we
can optimize our load distribution and match clients to the best
servers. It also gives better options for continuing support in case
of problems with segments of the client population. (See the links in
the basic guidelines section).