NTP Software Implementations Comparison

What’s NTP (Network Time Protocol)

This post is about NTP Software implementations actually, but I have to write some words about NTP. NTP is an angle for financial applications, actually some of services such as banking services are very depended to clock synchronizations protocols. NTP is an ancient thing, it is more than 30 years old and even older than Windows 7 and Windows XP.

NTP was designed by David L. Mills of the University of Delaware. I should thank the man more than Steve Jobs!

NTP is intended to synchronize all participating computers to within a few milliseconds of Coordinated Universal Time(UTC). It uses the intersection algorithm, a modified version of Marzullo’s algorithm, to select accurate time servers and is designed to mitigate the effects of variable network latency. NTP can usually maintain time to within tens of milliseconds over the public Internet, and can achieve better than one millisecond accuracy in local area networks under ideal conditions. Asymmetric routes and network congestion can cause errors of 100 ms or more.

The protocol is usually described in terms of a client-server model, but can as easily be used in peer-to-peer relationships where both peers consider the other to be a potential time source. Implementations send and receive timestamps using the User Datagram Protocol (UDP) on port number 123. They can also use broadcasting or multicasting, where clients passively listen to time updates after an initial round-trip calibrating exchange. NTP supplies a warning of any impending leap second adjustment, but no information about local time zones or daylight saving time is transmitted.

The current protocol is version 4 (NTPv4), which is a proposed standard as documented in RFC 5905. It is backward compatible with version 3, specified in RFC 1305.

You can also see my presentation about NTP and how it does work at SlideShare:


The NTP reference implementation, along with the protocol, has been continuously developed for over 20 years. Backwards compatibility has been maintained as new features have been added. It contains several sensitive algorithms, especially to discipline the clock, that can misbehave when synchronized to servers that use different algorithms. The software has been ported to almost every computing platform, including personal computers. It runs as a daemon called ntpd under Unix or as a service under Windows. Reference clocks are supported and their offsets are filtered and analysed in the same way as remote servers, although they are usually polled more frequently.

Software Implementations

NTP Implementations

NTP (RFC 5905):

  • The NTP Reference Implementation from The NTP Project at the University of Delaware. Includes a Simple NTP (SNTP) client.
  • Windows Port of NTPD: Free Windows port of The NTP Reference Implementation from http://www.ntp.org with an easy-to-use installer
  • NTPsec a hardened implementation derived from NTP Classic, Dave Mills’s original.
  • Chrony: Chronyd implements the NTP protocol and can act as either a client or a server.

Simple NTP (SNTP) Implementations

SNTP (RFC 4330):

  • OpenNTPD: A portable Simple NTPD implementation by the OpenBSD group
  • clockspeed: A simplest available and secure suite of NTP/SNTP client, clock skew eliminator, and precise time synchronization server and client
  • dntpd: A simple client ntpd in DragonFly BSD
  • ConnMan: ConnMan contains an NTP implementation.
  • BusyBox, since version 1.16.2, has included an SNTP client and server based on OpenNTP.
  • systemd-timesyncd: A linux and systemd specific client implementation of SNTP.

NTP Software Implementations Comparison

The below comparison is between NTPD, Chrony and OpenNTPD.

The ntpd program is an operating-system daemon that sets and maintains a computer system’s system time in synchronization with Internet-standard time servers. It is a complete implementation of the Network Time Protocol (NTP) version 4, but retains compatibility with versions 1, 2, and 3 as defined by RFC 1059, RFC 1119, and RFC 1305, respectively. ntpd performs most computations in 64-bit floating point arithmetic and uses 64-bit fixed point operations only when necessary to preserve the ultimate precision, about 232 picoseconds. While ordinary workstations and networks cannot achieve the ultimate precision as of 2015, future processors and networks may require it.

OpenNTPDIn 2004, Henning Brauer presented OpenNTPD, an NTP implementation with a focus on security and encompassing a privilege separated design. Whilst it is aimed more closely at the simpler generic needs of OpenBSD users, it also includes some protocol security improvements whilst still being compatible with existing NTP servers. It was originally designed for OpenBSD but has a portable version available and that has been made available as a package in Linux package repositories.

Chrony comes by default in Red Hat distributions and is available in the Ubuntu repositories. Chrony is aimed at ordinary computers, which are unstable, go into sleep mode or have intermittent connection to the Internet. Chrony is also designed for virtual machines, a much more unstable environment. It is characterized by low resource consumption (cost) and supports PTPas well as NTP. It has two main components: chronyd, a daemon that is executed when the computer starts, and chronyc, a command line interface to the user for its configuration. It has been evaluated as very safe and with just a few incidents, its advantage is the versatility of its code, written from scratch to avoid the complexity of code. Chrony is written under GNU General Public License version 2, was created by Richard Curnow in 1997 with others along time and is currently maintained by Miroslav Lichvar, development supported by Red Hat Software.

Feature Comparison

Basic Features

Supported systemsLinux, FreeBSD, NetBSD, Solaris, macOSLinux, FreeBSD, NetBSD, OpenBSD, Solaris, macOS, Windows, …​Linux, FreeBSD, NetBSD, OpenBSD, Solaris, macOS
Programming languageCCC
Size of stripped daemon binary in default configuration on Linux x86-64210 KB840 KB87 KB

Time Sources

Reference clocksYesYesYes
Manual inputYesNoNo

Source Tracking

Fixed sample filteringYesYesYes
Adaptive sample filteringYesNoNo
Sample weightingYesNoNo
Frequency trackingYesNoNo
Restore state from fileYesNoNo

Source Selection

Nonrandom selectionYesYesYes
Falseticker detectionYesYesNo
Offset combiningYesYesNo
Frequency combiningYesN/AN/A
Minimum number of sources1 (configurable)1 (configurable)1

Clock Discipline

Independent phase and frequency controlYesNoYes
Allowed random update interval (e.g. intermittent connection)YesNoYes
Step thresholdInfinity (configurable)0.128 s (configurable)N/A
Limited number of stepsYes (configurable)NoYes
Panic thresholdInfinity (configurable)1000 s (configurable)N/A
Maximum slew rateSystem specific (Linux: 100000 ppm, FreeBSD, NetBSD, macOS: 5000 ppm, Solaris: 32500 ppm) (configurable)500 ppmSystem specific (Linux: 500 ppm, FreeBSD, NetBSD: 5000 ppm, Solaris: 65000 ppm)
Restore frequency from fileYesYesYes
Limited wakeups (power saving)YesNoYes
Temperature compensationYesNoNo

NTP Modes

Server (mode 4)YesYesYes
Client (mode 3)YesYesYes
Persistent symmetricYesYesNo
Ephemeral symmetricNoYesNo
Broadcast serverYesYesNo
Broadcast clientNoYesNo
Multicast serverNoYesNo
Multicast clientNoYesNo
Manycast serverNoYesNo
Manycast clientNoYesNo
Interleaved serverYesNoNo
Interleaved clientYes?No
Interleaved symmetricYesYesNo
Interleaved broadcastNoYesNo

NTP Client

Multiple servers per name (pool)YesYesYes
Fixed delay-based sample filteringYesYesYes
Adaptive delay-based sample filteringYesNoNo
Estimation of asymmetric jitterYesNoNo
KoD RATE handlingYesYesNo
Ready for next NTP era (year 2036)YesYesNo
Extra timestamp validationNoNoYes (HTTPS date)
Configurable port numberYesNoNo

NTP Server

Protocol versionNTPv4NTPv4SNTPv4
Root dispersion/delay accumulationYesYesNo
Adaptive dispersion rateYesNoN/A
Restricted accessYesYesNo
Response rate limitingYesYesNo
Local referenceYesYesNo
Orphan modeYesYesNo
Served time not fixed to local timeYesNoYes
Time smoothingYesN/ANo
Configurable port numberYesNoNo

NTP Authentication

Symmetric keyYesYesNo
Autokey (insecure)NoYesNo
Network Time SecurityN/AN/AN/A
MS-SNTP via SambaYesYesNo
MAC hash functionsMD5, SHA-1, SHA-2, …​MD5, SHA-1, SHA-2, AES-CMAC, …​N/A

NTP Pool

Number of used serversBy DNS, max 4 (configurable)10 (configurable)By DNS
Replace unreachableYesYesNo
Replace falsetickersYesYesN/A

NTP Poll Control

Polling interval64-1024 s (configurable)64-1024 s (configurable)5-1500 s
Minimum configurable polling interval1/64 s8 sN/A
Interval independent from other sourcesYesYesNo
Aware of jitterYesYesNo
User-controlled pollingYesNoNo

NTP Timestamping

Kernel RX timestampingYesYesYes
Kernel TX timestampingYes (Linux)NoNo
Hardware RX timestampingYes (Linux)NoNo
Hardware TX timestampingYes (Linux)NoNo

Reference Clock

System driversPPS, PTP clock (Linux)PPSTimedelta sensors (OpenBSD)
Interfaces for 3rd party driversSHM, SOCKSHMNone
Number of HW-specific drivers0> 300
Sample filteringYesYesYes

Real-Time Clock (RTC)

Time initialization from RTCYes (Linux)NoNo
RTC drift trackingYes (Linux)NoNo
RTC trimmingYes (Linux)NoNo
Kernel RTC synchronizationYes (Linux, macOS)Yes (Linux)Yes (Linux)
Restore time from file w/o RTCYesNoNo

Leap Seconds

Clock correction modessystem, step, slew, ignoresystem, step, ignoreignore
Majority of sources required to agree on leapYesYesNo
Additional leap second sourcesystem tzdataleapfileN/A
Server leap smearYes (quadratic)Yes (cosine)N/A
Accepted onJun 30 / Dec 31any dayany day
Applied onJun 30 / Dec 31last day of any monthN/A
Announced onJun 30 / Dec 31last day of any monthany day

Run-time Management

Local monitoringYesYesYes
Local configurationYesYesNo
Remote monitoringYesYesNo
Remote configurationNo (chrony >= 2.2)YesNo
Restricted accessYesYesN/A


Root privileges dropping (in all processes)Yes (Linux)Yes (Linux, NetBSD, Solaris)No
Privilege separationYes (FreeBSD, NetBSD, macOS, Solaris)NoYes
System call filter (seccomp, pledge)Yes (Linux)Yes (Linux)Yes (OpenBSD)
Random NTP client source portYesNoYes
Fully random transmit timestamp in client packetsYesNoYes
Sub-second randomization of polling intervalYesNoNo
Connected NTP client socketsYesNoYes
NTP server port disabled by defaultYesNoYes
Remote management disabled by defaultN/ANoN/A
Remote management port separate from NTPYesNoN/A
No traffic amplification in management protocolYesNoN/A
Non-blocking response rate limitingYesNoN/A

Summary of Comparison of Chrony and NTPD

Things Chrony Can Do Better Than NTP

  • Chrony can perform usefully in an environment where access to the time reference is intermittent. NTP needs regular polling of the reference to work well.
  • Chrony can usually synchronize the clock faster and with better time accuracy.
  • Chrony quickly adapts to sudden changes in the rate of the clock (e.g. due to changes in the temperature of the crystal oscillator). NTP may need a long time to settle down again.
  • Chrony can perform well even when the network is congested for longer periods of time.
  • Chrony in the default configuration never steps the time to not upset other running programs. NTP can be configured to never step the time too, but in that case it has to use a different means of adjusting the clock (daemon loop instead of kernel discipline), which may have a negative effect on accuracy of the clock.
  • Chrony can adjust the rate of the clock in a larger range, which allows it to operate even on machines with broken or unstable clock (e.g. in some virtual machines).
  • Chrony is smaller, it uses less memory and it wakes up the CPU only when necessary, which is better for power saving.

Things Chrony Can Do That NTP Can’t

  • Chrony supports hardware time-stamping on Linux, which allows extremely accurate synchronization on local networks.
  • Chrony provides support for isolated networks whether the only method of time correction is manual entry (e.g. by the administrator looking at a clock). Chrony can look at the errors corrected at different updates to work out the rate at which the computer gains or loses time, and use this estimate to trim the computer clock subsequently.
  • Chrony provides support to work out the gain or loss rate of the real-time clock, i.e. the clock that maintains the time when the computer is turned off. It can use this data when the system boots to set the system time from a corrected version of the real-time clock. These real-time clock facilities are only available on Linux, so far.

Things NTP Can Do That Chrony Can’t

  • NTP supports all operating modes from RFC 5905, including broadcast, multicast, and manycast server/client. However, the broadcast and multicast modes are inherently less accurate and less secure (even with authentication) than the ordinary server/client mode, and should generally be avoided.
  • NTP supports the Autokey protocol (RFC 5906) to authenticate servers with public-key cryptography. Note that the protocol has been shown to be insecure and it will be probably replaced with an implementation of the Network Time Security (NTS) specification.
  • NTP has been ported to more operating systems.
  • NTP includes a large number of drivers for various hardware reference clocks. Chrony requires other programs (e.g. gpsd or ntp-refclock) to provide reference time via the SHM or SOCK interface.

See Also

[Script]: Check Time Synchronization with Host on Virtual Machines – PowerCLI


Davoud Teimouri

Davoud Teimouri is as a professional blogger, vExpert 2015/2016/2017/2018/2019/2020/2021/2022, vExpert NSX, vExpert PRO, vExpert Security, VCA, MCITP. This blog is started with simple posts and now, it has large following readers.

Leave a Reply

Your email address will not be published. Required fields are marked *