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.ancient

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

chrony ntp openntpd
Supported systems Linux, FreeBSD, NetBSD, Solaris, macOS Linux, FreeBSD, NetBSD, OpenBSD, Solaris, macOS, Windows, …​ Linux, FreeBSD, NetBSD, OpenBSD, Solaris, macOS
License GPLv2 MIT + BSD BSD
Programming language C C C
Size of stripped daemon binary in default configuration on Linux x86-64 210 KB 840 KB 87 KB

Time Sources

chrony ntp openntpd
NTP Yes Yes Yes
Reference clocks Yes Yes Yes
Manual input Yes No No

Source Tracking

chrony ntp openntpd
Fixed sample filtering Yes Yes Yes
Adaptive sample filtering Yes No No
Sample weighting Yes No No
Frequency tracking Yes No No
Restore state from file Yes No No

Source Selection

chrony ntp openntpd
Nonrandom selection Yes Yes Yes
Falseticker detection Yes Yes No
Clustering No Yes No
Offset combining Yes Yes No
Frequency combining Yes N/A N/A
Minimum number of sources 1 (configurable) 1 (configurable) 1

Clock Discipline

chrony ntp openntpd
Independent phase and frequency control Yes No Yes
Allowed random update interval (e.g. intermittent connection) Yes No Yes
Step threshold Infinity (configurable) 0.128 s (configurable) N/A
Limited number of steps Yes (configurable) No Yes
Panic threshold Infinity (configurable) 1000 s (configurable) N/A
Maximum slew rate System specific (Linux: 100000 ppm, FreeBSD, NetBSD, macOS: 5000 ppm, Solaris: 32500 ppm) (configurable) 500 ppm System specific (Linux: 500 ppm, FreeBSD, NetBSD: 5000 ppm, Solaris: 65000 ppm)
Restore frequency from file Yes Yes Yes
Limited wakeups (power saving) Yes No Yes
Temperature compensation Yes No No

NTP Modes

chrony ntp openntpd
Server (mode 4) Yes Yes Yes
Client (mode 3) Yes Yes Yes
Persistent symmetric Yes Yes No
Ephemeral symmetric No Yes No
Broadcast server Yes Yes No
Broadcast client No Yes No
Multicast server No Yes No
Multicast client No Yes No
Manycast server No Yes No
Manycast client No Yes No
Interleaved server Yes No No
Interleaved client Yes ? No
Interleaved symmetric Yes Yes No
Interleaved broadcast No Yes No

NTP Client

chrony ntp openntpd
Multiple servers per name (pool) Yes Yes Yes
Fixed delay-based sample filtering Yes Yes Yes
Adaptive delay-based sample filtering Yes No No
Estimation of asymmetric jitter Yes No No
KoD RATE handling Yes Yes No
Ready for next NTP era (year 2036) Yes Yes No
Extra timestamp validation No No Yes (HTTPS date)
Configurable port number Yes No No

NTP Server

chrony ntp openntpd
Protocol version NTPv4 NTPv4 SNTPv4
Root dispersion/delay accumulation Yes Yes No
Adaptive dispersion rate Yes No N/A
Restricted access Yes Yes No
Response rate limiting Yes Yes No
Local reference Yes Yes No
Orphan mode Yes Yes No
Served time not fixed to local time Yes No Yes
Time smoothing Yes N/A No
Configurable port number Yes No No

NTP Authentication

chrony ntp openntpd
Symmetric key Yes Yes No
Autokey (insecure) No Yes No
Network Time Security N/A N/A N/A
MS-SNTP via Samba Yes Yes No
MAC hash functions MD5, SHA-1, SHA-2, …​ MD5, SHA-1, SHA-2, AES-CMAC, …​ N/A

NTP Pool

chrony ntp openntpd
Number of used servers By DNS, max 4 (configurable) 10 (configurable) By DNS
Replace unreachable Yes Yes No
Replace falsetickers Yes Yes N/A

NTP Poll Control

chrony ntp openntpd
Polling interval 64-1024 s (configurable) 64-1024 s (configurable) 5-1500 s
Minimum configurable polling interval 1/64 s 8 s N/A
Randomization Yes Yes Yes
Burst Yes Yes No
Interval independent from other sources Yes Yes No
Aware of jitter Yes Yes No
User-controlled polling Yes No No

NTP Timestamping

chrony ntp openntpd
Kernel RX timestamping Yes Yes Yes
Kernel TX timestamping Yes (Linux) No No
Hardware RX timestamping Yes (Linux) No No
Hardware TX timestamping Yes (Linux) No No

Reference Clock

chrony ntp openntpd
System drivers PPS, PTP clock (Linux) PPS Timedelta sensors (OpenBSD)
Interfaces for 3rd party drivers SHM, SOCK SHM None
Number of HW-specific drivers 0 > 30 0
Sample filtering Yes Yes Yes

Real-Time Clock (RTC)

chrony ntp openntpd
Time initialization from RTC Yes (Linux) No No
RTC drift tracking Yes (Linux) No No
RTC trimming Yes (Linux) No No
Kernel RTC synchronization Yes (Linux, macOS) Yes (Linux) Yes (Linux)
Restore time from file w/o RTC Yes No No

Leap Seconds

chrony ntp openntpd
Clock correction modes system, step, slew, ignore system, step, ignore ignore
Majority of sources required to agree on leap Yes Yes No
Additional leap second source system tzdata leapfile N/A
Server leap smear Yes (quadratic) Yes (cosine) N/A
Accepted on Jun 30 / Dec 31 any day any day
Applied on Jun 30 / Dec 31 last day of any month N/A
Announced on Jun 30 / Dec 31 last day of any month any day

Run-time Management

chrony ntp openntpd
Local monitoring Yes Yes Yes
Local configuration Yes Yes No
Remote monitoring Yes Yes No
Remote configuration No (chrony >= 2.2) Yes No
Restricted access Yes Yes N/A

Security

chrony ntp openntpd
Root privileges dropping (in all processes) Yes (Linux) Yes (Linux, NetBSD, Solaris) No
Privilege separation Yes (FreeBSD, NetBSD, macOS, Solaris) No Yes
System call filter (seccomp, pledge) Yes (Linux) Yes (Linux) Yes (OpenBSD)
Random NTP client source port Yes No Yes
Fully random transmit timestamp in client packets Yes No Yes
Sub-second randomization of polling interval Yes No No
Connected NTP client sockets Yes No Yes
NTP server port disabled by default Yes No Yes
Remote management disabled by default N/A No N/A
Remote management port separate from NTP Yes No N/A
No traffic amplification in management protocol Yes No N/A
Non-blocking response rate limiting Yes No N/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

Professional blogger, vExpert 2015/2016/2017/2018/2019/2020/2021/2022/2023, vExpert NSX, vExpert PRO, vExpert Security, vExpert EUC, 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 *