How to Configure Chrony NTP Time Synchronization, PPS Precision Hardware Clocks, and PTP on Ubuntu Server

Distributed database consensus engines (such as CockroachDB and Ceph), financial trading platforms, and cryptographic signing authorities rely on microsecond-level clock accuracy across server clusters. While Ubuntu Server ships with systemd-timesyncd as its default SNTP time client, that service lacks support for sub-millisecond disciplining, local hardware reference clocks, and Precision Time Protocol (PTP). Chrony (consisting of the chronyd daemon and chronyc control utility) is the industry standard for high-accuracy Network Time Protocol (NTP) synchronisation on modern Linux distributions.

By configuring Chrony on Ubuntu Server, systems engineers can interface with public stratum-1 time pools, bind to hardware Pulse-Per-Second (PPS) signals derived from GNSS/GPS receivers, and leverage network interface card (NIC) hardware timestamping via PTP to maintain sub-microsecond time discipline.

Architectural Overview: Time Synchronization Mechanisms

Clock disciplining in Linux coordinates multiple layers, from physical crystal oscillators to software network time protocols:

Protocol / Mechanism	Standard Reference	Typical Precision	Primary Use Case
SNTP (systemd-timesyncd)	RFC 4330	10–50 ms	Lightweight client machines; non-distributed desktop workloads.
NTP via Chrony	RFC 5905 (NTPv4)	0.1–1.0 ms (WAN) / < 50 µs (LAN)	Production server clusters, database nodes, enterprise authentication realms.
PPS (Pulse-Per-Second)	Hardware Interrupt	< 1 µs	Physical stratum-1 time servers paired with GPS/GNSS serial receivers.
PTP (Precision Time Protocol)	IEEE 1588-2008 / 1588-2019	< 100 ns	Low-latency financial exchanges, telecom 5G RAN, high-frequency telemetry.

Disabling systemd-timesyncd and Installing Chrony

Ubuntu Server activates systemd-timesyncd out of the box. Running multiple time daemons concurrently creates race conditions that disrupt the Linux kernel clock disciplining loop.

Step 1: Deactivate the Default SNTP Client

# Stop and disable systemd-timesyncd
sudo systemctl stop systemd-timesyncd
sudo systemctl disable systemd-timesyncd
sudo systemctl mask systemd-timesyncd

Step 2: Install Chrony

# Update APT repositories and install chrony
sudo apt update && sudo apt install -y chrony

# Verify daemon status
sudo systemctl status chrony

Configuring Stratum Pools and Step Thresholds in chrony.conf

The primary configuration file for Chrony is located at /etc/chrony/chrony.conf. Edit this file to establish resilient upstream time sources and initialisation behaviour:

# Open configuration in nano or vim
sudo nano /etc/chrony/chrony.conf

Configuring Optimal Directives

Replace or amend the default pool configuration with vetted, geographically close stratum sources:

# Use regional UK/European NTP pools with aggressive initial burst polling
pool uk.pool.ntp.org iburst maxsources 4
pool time.cloudflare.com iburst
pool time.google.com iburst

# Allow chronyd to step the system clock rather than slewing if the offset is larger
# than 1.0 second, but only during the first 3 clock updates after startup
makestep 1.0 3

# Record the rate at which the system clock gains or loses time
driftfile /var/lib/chrony/chrony.drift

# Step the real-time clock (RTC / CMOS) every 11 minutes
rtcsync

# Specify log directory and event tracking
logdir /var/log/chrony
log measurements statistics tracking

The makestep 1.0 3 directive is critical for virtualised or cloud-hosted instances: it allows Chrony to instantly step the clock forward or backward if a virtual machine resumes from suspend or boots with a severe time skew, preventing database consensus deadlocks.

Integrating a Hardware Pulse-Per-Second (PPS) Clock

For dedicated hardware appliances equipped with a GPS receiver emitting a physical 1 PPS signal over GPIO or RS-232 serial (DCD pin), Chrony can directly discipline the kernel clock using Linux PPS interfaces (/dev/ppsX).

Step 1: Install PPS Tools and Verify Kernel Module

# Install pps-tools package
sudo apt install -y pps-tools

# Ensure the pps_core kernel module is loaded
sudo modprobe pps_core
lsmod | grep pps

Step 2: Test the PPS Hardware Signal

# Query the PPS device (e.g. /dev/pps0)
sudo ppstest /dev/pps0

The terminal should output a sequence of source timestamps incrementing exactly once per second with sub-microsecond jitter:

source 0 - assert 1729747200.000001243, sequence: 1042 - clear 0.000000000, sequence: 0

Step 3: Bind PPS to Chrony

Append the reference clock directive to /etc/chrony/chrony.conf:

# Define PPS reference clock
# refid: 4-character identifier
# precision: estimated resolution (1e-7 = 100 nanoseconds)
refclock PPS /dev/pps0 refid PPS precision 1e-7 poll 0 prefer

When paired with an NMEA serial source or public NTP servers to resolve the coarse second, the PPS clock locks the sub-second offset down to nanosecond precision.

Leveraging Precision Time Protocol (PTP) and Hardware Timestamping

Precision Time Protocol (IEEE 1588) relies on network interface cards that timestamp incoming and outgoing Ethernet packets at the physical PHY layer, eliminating operating system kernel scheduling latency.

Step 1: Check NIC Hardware Timestamping Capabilities

# Query the primary network interface (e.g. eth0 or enp3s0)
ethtool -T eth0

Verify that the output reports:

Capabilities:
    hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
    software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
    hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
    hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0

Step 2: Bind PTP Hardware Clock (PHC) to Chrony

When PTP Hardware Clock: 0 is available, the device node /dev/ptp0 exists. Add this to /etc/chrony/chrony.conf:

# Discipline clock using PHC directly
refclock PHC /dev/ptp0 poll 0 dpoll -2 precision 1e-9 refid PTP

Restart Chrony to apply the updated configuration:

sudo systemctl restart chrony

Operational Verification and Monitoring with chronyc

Use the chronyc interactive client to evaluate synchronisation health and offset metrics:

Step 1: Inspect Upstream Sources

chronyc sources -v

Look at the selection state character in the first column:

• * (Best Source): The current reference source used for system clock synchronisation.
• + (Combined): Acceptable sources being combined into the multi-source filtering algorithm.
• - (Excluded): Considered outliers and discarded by the cluster algorithm.
• ? (Unreachable): Packet exchange failed or firewall blocked UDP port 123.

Step 2: Inspect Source Statistics and Variance

chronyc sourcestats -v

Examine the Std Dev column: on a properly tuned LAN or stratum-1 setup, standard deviation should remain below 50us.

Step 3: Query System Tracking Status

chronyc tracking

Provides critical diagnostic parameters including Reference ID, Stratum, System time offset, and Root delay.

Troubleshooting Chrony Time Synchronization Anomalies

Consult this diagnostic matrix to resolve synchronisation failures:

Symptom	Probable Root Cause	Remediation Procedure
chronyc sources shows all servers with ? state.	Outbound UDP port 123 blocked by host firewall (UFW/iptables) or cloud security group.	Allow outbound UDP port 123 using sudo ufw allow out 123/udp. Ensure network gateways do not drop NTP traffic.
System clock drifts significantly during high CPU load.	Kernel timer interrupt starvation or virtual machine CPU throttling.	Switch kernel clocksource from acpi_pm or hpet to tsc: echo tsc | sudo tee /sys/devices/system/clocksource/clocksource0/current_clocksource.
“506 Cannot talk to daemon” when running chronyc.	chronyd service crashed or is not running, or Unix control socket permission denied.	Check service status via journalctl -u chrony -e. Verify socket exists at /run/chrony/chronyd.sock.
PPS refclock shows x (falseticker) state in chronyc sources.	PPS signal is arriving without a reliable secondary source to provide the absolute coarse second.	Ensure at least two internet NTP pool servers or local NMEA serial devices are active alongside the PPS line.

Implementing Chrony with PPS and PTP hardware disciplining on Ubuntu Server ensures resilient, audit-compliant temporal integrity across enterprise computing fabrics.