Synchronizing the clocks with NTP - a simple intro.

Frank Helk
This article provides some basic insights on NTP and how to install and config a NTP client.


There are many applications where some computing systems need to have their system clocks running synchronized within a small margin and eventually need to be in sync with the global time.

There are different solutions for this, i.e. the W32time service on Windows machines, or some more OS specific solutions. One of the most widespread solutions for this is the Network Time Protocol, short NTP. This beauty is around for a long time (published in September 1985), and implementations of the protocol exist for various operating systems, i.e.

Besides of that there's source code for the NTP client available in various programming languages C, Perl, Python, Ruby, and TCL for the harder kind of users. There's even an implementation in Java (SNTP only). This wide spread system base and the long history and development of NTP has led to a mature and extremely stable product.

Background - What does NTP, and what's SNTP ?

As lined out before, NTP is a background service that synchronizes the system clock with the clock of another, remote system. NTP does that by fine-tuning the system clock ticks to drive it smoothly into sync with the time master's clock. Afterwards it keeps it following the master's clock as close as possible by constantly monitoring the time diff and retune the ticks if needed. This behavior is very kind to software that reacts with bad hiccups if the system time does hard steps - which I've seen often, especially when systems step backwards.

Behind the scene it keeps complex statistics and irons out the uncertainties resulting from varying network timing conditions and influence of network load. And it is capable of monitoring several master systems at once and choose the most reliable time source of the moment.

Besides of that any NTP client is a NTP server, too. This enables the creation of time chains, at the cost of precision due to accumulating uncertainties.

SNTP is the little brother of NTP. It is based on the same protocols and calls regular NTP servers to get the time, but it doesn't contain the complex algorithms of the "full" NTP client. It calls an NTP in given intervals and does a hard time step of the system clock. It is meant for simple systems like network switches that need some kind of time sync for logging but could afford the hard time steps otherwise.

Installation & Configuration

I don't want to go into all the bells & whistles of NTP in this intro. It contains lots of features like security and diagnostics - if you're interested in these, please refer to the NTP documentation  (but be aware that the docs are kind of hard stuff ...).

On most (if not all) Unix like operating systems (i.e. Linux or HP-UX) the NTP service ntpd is already part of the system and only needs to be properly configured. On Linux systems the GUI setup tools like YAST contain configuration programs for that. You'll have to set up the service to be started at boot time with a run level editor.

On other operating systems, esp. Windows, NTP is commonly NOT part of the OS and needs to be installed like any other application. The installers of the usual NTP ports mostly explain themselves. Just download your preferred package and install.

In newer incarnations of Windows, the native timekeeping service W32time is capable of acting as NTP service, too. From my experience, I recommend to just disable it (which is necessary anyway if you use an original NTP port) and waste no further thought about using it. You ask why ?
The first argument for that is the fact that W32time proved to be a bit unstable whenever I tried it. But that is my personal experience ...

The second argument: The diagnostic features of W32time are rudimentary compared with the features of classic NTP.

The third argument: The configuration of W32time is not that much clear and simple as the configuration of a classic NTP client. You have to set it up with cryptic command line options and it's a hassle to retrieve the actual settings.
Besides of that a hint: In rare cases the windows installers fail to disable the W32time service. This results in two services manipulating the system clock, which leads to very interesting (and disgusting) results. If NTP on Windows gives weird results, first check if the W32time service is disabled.

The configuration of the classic NTP service is done mostly by an configuration file named ntp.conf (whose most important options I'll describe below) and some command line parameters (which I like to omit here, because they are seldom used. Please refer to the original NTP documentation if you feel the urge to  do so). On Unix-like systems the man pages provide detailed information about all the supported commands and options, they can be accessed with the commands

man ntpd
man ntp.conf
The file ntp.conf is located

on Unix-like machines in /etc

on Windows machines usually (!) in %WINDIR%\system32\drivers\etc
On Windows machines some NTP client implementations store the file in other locations, so you might search for it if the installer doesn't tell you where it is. But it's named ntp.conf in any case.
The most simple ntp.conf file would look like this:
driftfile %windir%\\ntp.drift
logfile C:\temp\ntp.log

# Example file paths for UNIX-like systems:
# driftfile /var/lib/ntp/drift/ntp.drift
# logfile /var/log/ntp
And that's a working configuration in almost all cases - even when it could afford some enhancements.

To begin with the more simple directives, the driftfile tells the NTP service where to store a file with a value that tells NTP at the next startup with what clock correction value to begin. The file is pretty small, it contains just one single numeric value. It should be in a location where it didn't get deleted and where the NTP service has full access to it. The example also shows that NTP is capable of using environment variable in the configuration file. The variable windir usually points to c:\windows on Windows systems.

The logfile  directive does exactly what its name implies - it defines where the NTP service should keep its log file and what name is desired for it.

The line with the server keyword tells the NTP service to communicate with the specified server. Given a working name resolution on your station, you can specify the server by name or IP address. You may specify more than one server by adding more server lines, i.e.

driftfile %windir%\\ntp.drift
logfile C:\temp\ntp.log
There are some more directives to the server line, of which I'll show you the common things I mostly use.

First of all - and applied in most cases - is the iburst option. It takes no parameters. If that keyword is used, the NTP service contacts the server frequently at startup to reach a sufficient statistic - and thereby sync - as fast as possible.

The option prefer tells the service to sync preferably to this server as long as this poses no significant performance losses. No parameters, either.

The option noselect is somewhat special - it tells the service to contact and monitor that server (i.e. for diagnostic reasons) but never to sync to it. Again one without parameters.

The options minpoll and maxpoll control how often the NTP service contacts the specified server. Normally NTP decides by itself how often it is necessary to ask a remote server for the time. The more stable the roundtrip times (and other things) are, the less frequent NTP would need to call the server. The allowed range of the intervals is from once every 8 seconds to once every 131072 seconds (approx. one and a half day), while the automatic determination chooses values from 64 seconds to 1024 seconds. Minpoll (for the shortest allowed interval) and maxpoll (for the longest allowed interval) take a single numeric parameter in the range of 3 ... 17, which gives the poll interval length as a power of two. That means a parameter of 6 equals to 2^6 = 64 seconds, a parameter of 10 equals to 2^10 = 1024 seconds.

A somewhat complex server entry might look like this way:
server iburst minpoll 6 maxpoll 10 prefer
Taking the parameters in, an enhanced ntp.conf file - that will work in most environments - might be

server iburst minpoll 6 maxpoll 10 prefer
server iburst minpoll 6 maxpoll 10 
server iburst minpoll 6 maxpoll 10 
server iburst minpoll 6 maxpoll 10 
driftfile %windir%\\ntp.drift
logfile C:\temp\ntp.log

By the way: Every line beginning with # is considered a comment.

A few words on

If you don't know where to get the time from, the project is a good point to start at.

The project manages a large pool of (or more precise, a list) of NTP servers around the world, which are operated by several organizations and individuals. The project offers a variety of DNS entries that point to servers from the pool. There's a worldwide set (which I've used for the examples above), some "continental" sets (i.e. for servers in Europe) and "country" sets for servers from a country (i.e. for servers in Germany). The servers that the DNS entries point to are change hourly to distribute the load. Please refer to the project's homepage for details.

Do the initial sync

When starting, the NTP service checks the current time against the time of the first called server. If the difference is too big, the service exits with an error (this could be circumvented by the command line parameter -g, please refer to the docs for more).

This behaviour requires you to manually set the clock to differ not more than 1000 seconds from the real time before starting the service. The subsequent sync of the clock would take some time afterwards, depending on the offset.

But there's a nicer way to achieve the initial synchronization. The ntp service executable program, unsually named ntpd or xntpd on Unix-like systems and ntpd.exe on Windows systems, could do this for you in a very precise way. First, ensure that the NTP service is not running already. If needed, stop it. Then run the NTP service executable from the command line with the options -g -q

The NTP program will step the clock to the reference time depending on the given configuration file and exit afterwards. If your configuration file is located an unexpected place, you'll need to tell the program where to find it with -c .

Another, older and now deprecated way is the ntpdate program. It is called in this way:

ntpdate <server>
On Windows systems, it might need the option -b. This command syncs the local clock to the time of server with a hard step.

After setting the time for the first time, just start the service and enjoy.

Other time sources

If the synced system don't have internet access, there are other ways to get reliable time. The most sophisticated way would be to run your own atomic clock, but I bet that most of us couldn’t afford one.

The next best solution would be a dedicated time server with a radio controlled clock. Such devices are supplied by many vendors and they are equipped with time signal receivers for i.e. GPS, DCF77, and others. They sync their internal clock with the radio signal and supply the time to the client by NTP and other protocols. For periods with disturbed radio signals they're usually equipped with a precision quartz clock as backup device. Unfortunately they cost about twice of a simple PC.

A cost effective solution would be to plug a radio controlled clock card into an old PC (the task is simple, anything from Pentium III upwards with W2k+ should do, and a small Linux machine would be fine for that) and install a matching NTP port on it.

The more experienced and nerdy people use some radio clock module along with and a mirco computer linke an Arduiono or a Raspberry Pi to roll their own radio controlled time servers. An internet search for "raspberry pi DCF77 receiver" would match plenty of recipes for such a project ...

Time server chains

Just some arguments about chains of time servers. NTP allows to chain time servers, meaning you could sync a central station with an external time server, sync some secondary stations to this and let sync groups of clients to these secondary machines. Possible, but unwise.

The first drawback is loss of precision. The synchronization via NTP (and any other time service protocol) comes with uncertainties - there's no perfect sync possible. If you chain time severs, each layer adds its own uncertainties to the distributed time. The more layers, the more deviation at the last link in the chain.

The second drawback is availability. Referring to the  example above, if the central stations goes down, all clients are cut off the time sync and will drift away from the current time. If a secondary station goes down, its client group will drift away.

If all clients have internet access (maybe tailored down to the NTP protocol only), all clients sync with various servers from the pool mentioned above. There might be uncertainties due to poor network responses, but NTP irons that out in most cases. And a server that goes down would in most cases not infer your clients in any way.


NTP clients contain a fine diagnostic tool named ntpq. The most used call of it would be

ntpq -p
meaning "show peer statistics".

With that command you'll get a list reflecting the configured servers, and the statistics of the recent calls to them.

Please refer to the ntpq documentation for more details and especially for the tally codes here (search for "Select Field" in the "Peer Status Word"). In short, a * preceding the server name or IP tells that this is the server NTP is currently synchronizing to, and a preceding + tells that this server is one of the next best ones designated as backup time sources. An empty space tells "not yet finally rated" and any other sign usually marks problems with that server. Don't worry about temporary problem markers; they might be corresponding to network load spikes.

After all, NTP is a mature, reliable and very accurate method for synchronizing the clocks of computer systems. If set up properly, it is a "set up once and forget" solution, because it then usually works silently and smooth - and won't disturb you further.

Things beyond a basic intro

This chapter is for some additional remarks I got from other experts, which are a bit beyond a basic intro but too good to be omitted (I'd be happy about addtional tips-'n-tricks feedback to be added here):
  • [noci]: Besides the classic NTP client and its various ports for non-UX operating system, there are some projects which work similar (and probably interoprable). Notably are i.e.
    • openntpd (used by OpenBSD), see
    • chrony (used by CentOS 8, RHEL8), see
  • [noci]: The classic NTP client is capable of using clocks attached by RS232 interfaces (like i.e. the HOPF Model 4065) and - for the more nerdy of us - radio receiver modules with pulse output of i.e. DCF77 time telegrams. The latter would be attached to modem status lines on a RS232 port like shown here:
  • [noci]: On VM's  guests you may experience a huge time loss, mostly because the clock interrupt is missing ticks when other guest systems are active. This may result in a huge skew or at least less stable synchronization of the clock. In those cases a low maxpoll setting of 6  or 7 may be a lot better in keeping the time on track.

    Another solution might be to omit NTP from the guest, sync the VM host with NTP and distribute time to the gues(s) by means of the virtualization software (i.e. "VMWare Tools").

Further Information and References:

Official NTP homepage
NTP cheat sheet (from Meinberg)
NTP server pool project homepage
Publishers of Time and Frequency Software
RFC 958, "Network Time Protocol (NTP)"
List of Windows Ports of the NTP Software
Frank Helk

Comments (3)

Interesting article! Typical Microsoft, reinventing the wheel with something overly complicated, which doesn't quite work!

I am interested to find out more about what you mean by

In rare cases the windows installers fail to disable the W32time service. This results in two services manipulating the system clock, which leads to very interesting (and disgusting) results. If NTP on Windows gives weird results, first check if the W32time service is disabled.

Sounds very much like a problem I am experiencing but cannot nail down.


Thank you for the positive feedback. You might also give me my first "Yes" in the feedback corner at the end of the article if you feel the urge :-)

To your question:

Since the problems arising from two services manipulating the system clock are obvious, the installer of the Windows port tries to do what's needed: Stop W32time and disable it (it's set for automatic start at system boot by default).

Sometimes the installer fails to do that, leaving W32time active and on "autostart at boot" - probably due to permissions problems on the specific system. To correct that, all you have to do is to run services.msc, find the Windows time keeper service, stop it, and set it to "Disabled" in its options dialog.
Hope that helps ...
nociSoftware Engineer
Distinguished Expert 2023

Also consider openntpd used by OpenBSD:
CentOS 8 (RHEL8) started to use chrony:
Both look a lot like the original ntp program only without all the fancy support for  pulse coded systems etc.

the original ntpd can take input from pulse type clocks like DCF-77.  This can be run using a modem control line from an RS-232 if there is a DCF-77 tuner available the provides the pulse on the modem control line. (The modem control line can issue an interrupt on the host CPU making it more efficient that polling some serial line to detect pulses). such tuner-boards are available for a few bucks.
(it can be "simple"

Another point in consideration:
On VM's  guest may experience a huge time loss. Mostly because the clock interrupt is missing ticks when other guest systems are active. This may result in a huge skew of the clock. In those cases a maxpoll of 6  or 7 maybe is a lot better in keeping the time on track.
(It often helps best by installing guest-tools or whatever they are called for the host system in question. although those might not always be available if not using a recent windows, or linux).

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.