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.
OpenNTPD, In 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