EN FR

NTP Troubleshooting Guide

Step-by-step solutions for common time synchronization problems

Understanding Time Offset

Time offset is the difference between your system clock and the reference NTP server. Here's how to interpret offset values:

Offset Range Status Action Required
< 100ms Excellent No action needed
100ms - 500ms Acceptable Monitor, may need tuning
500ms - 1s Warning Check NTP configuration
> 1 second Critical Immediate action required

Fixing Clock Skew & Drift

Problem: Gradual Time Drift

Your system time slowly drifts away from the correct time, even with NTP running.

Common Causes

Solution: Check Hardware Clock

Compare your hardware clock with system time:

# Check hardware clock (RTC)
sudo hwclock --show

# Compare with system time
date

# Sync hardware clock from system time
sudo hwclock --systohc

Solution: Adjust Polling Interval

For systems with high drift, reduce the polling interval:

# In /etc/ntp.conf, add minpoll/maxpoll
server pool.ntp.org minpoll 4 maxpoll 6

# Or for chrony (/etc/chrony/chrony.conf)
server pool.ntp.org minpoll 4 maxpoll 6

Network Latency Issues

Problem: High Network Latency

Network delays cause inaccurate time synchronization and unstable offsets.

Diagnosing Latency

# Test latency to NTP server
ping -c 10 pool.ntp.org

# Check NTP round-trip delay
ntpq -p
# Look at the "delay" column (in milliseconds)

Solution: Use Closer NTP Servers

Select geographically closer servers to reduce latency:

# Use regional pool servers
# Europe
server 0.europe.pool.ntp.org
server 1.europe.pool.ntp.org

# France specifically
server 0.fr.pool.ntp.org
server 1.fr.pool.ntp.org

# Or use RDEM Systems (European infrastructure)
server ntp.rdem-systems.com

High Jitter Problems

Problem: Unstable Time Measurements

The "jitter" value in ntpq output is high (>10ms), indicating inconsistent time samples.

Understanding Jitter

Jitter measures the variation in round-trip delay. High jitter indicates network instability or server issues.

# Check jitter values
ntpq -p
# The "jitter" column shows measurement stability

# Good: < 5ms
# Acceptable: 5-20ms
# Poor: > 20ms

Solution: Configure Multiple Servers

Use multiple NTP servers so the algorithm can filter out unstable sources:

# /etc/ntp.conf - use at least 4 servers
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst

# The 'iburst' option speeds up initial sync

Large Time Offset (>1000 seconds)

Problem: Time Off by Minutes or Hours

NTP refuses to correct large time differences (>1000 seconds by default).

Why This Happens

NTP has a "panic threshold" (default 1000 seconds) to prevent accidental large time jumps that could corrupt databases or logs.

Solution: Manual Time Correction

First, manually set approximate time, then let NTP fine-tune:

# Stop NTP service first
sudo systemctl stop ntpd    # or chronyd

# Set time manually (rough sync)
sudo ntpdate -b pool.ntp.org

# Or use timedatectl
sudo timedatectl set-time "2025-01-14 10:30:00"

# Restart NTP
sudo systemctl start ntpd

Alternative: Force Step Correction

Allow NTP to make large corrections (use with caution):

# For ntpd: add -g flag to allow first large step
# Edit /etc/sysconfig/ntpd or service file
OPTIONS="-g"

# For chrony: use makestep directive
# /etc/chrony/chrony.conf
makestep 1 3  # Step if offset > 1s, first 3 updates

Quick Fixes Checklist

5-Minute NTP Health Check

  1. Is NTP running? systemctl status ntpd or systemctl status chronyd
  2. Are servers reachable? ntpq -p - check "reach" column (should be 377)
  3. Is firewall open? sudo ufw status - UDP 123 must be allowed
  4. What's the offset? ntpq -p - check "offset" column
  5. Force a sync: sudo systemctl restart ntpd

Still Having Issues?

For advanced diagnostics or enterprise NTP infrastructure needs:

Run Live Test CLI Commands Enterprise NTP