Note: This article was originally published in 2019. Commands and package names have been updated for Ubuntu 22.04 LTS and 24.04 LTS. The techniques also apply to Debian and other Debian-based distributions.

When setting up an NTP (Network Time Protocol) server for your local network, verifying that clients can successfully connect and synchronize is essential. A misconfigured NTP server, firewall rule, or DNS issue can silently leave your machines with drifting clocks, which causes problems ranging from Kerberos authentication failures to inaccurate log timestamps. This guide covers every tool available on Ubuntu for testing NTP connectivity.

Prerequisites

Before testing, ensure you have:

  • An Ubuntu client machine (18.04 LTS or later).
  • Network connectivity to the NTP server you want to test.
  • sudo access for installing packages and modifying system settings.

Method 1: Using ntpdate (Query Mode)

The ntpdate utility is the simplest way to perform a one-shot query against an NTP server. The -q flag makes it query-only, meaning it reports the time offset without modifying your system clock.

Installation

# On Ubuntu 22.04+ / Debian 12+
sudo apt install ntpsec-ntpdate

# On older Ubuntu versions (18.04, 20.04)
sudo apt install ntpdate

Query an NTP Server

# Query a public NTP pool
ntpdate -q pool.ntp.org

# Query a specific NTP server by IP
ntpdate -q 10.0.1.5

# Query a specific NTP server by hostname
ntpdate -q ntp.internal.example.com

Example output:

2024-12-16 21:57:34.671300 (+0000) +0.031568 +/- 0.103280 pool.ntp.org 84.245.9.254 s1 no-leap

Breaking down the output:

FieldMeaning
2024-12-16 21:57:34.671300Timestamp of the query
(+0000)UTC offset
+0.031568Time offset — your clock is 0.031 seconds ahead of the server
+/- 0.103280Error margin of the measurement
pool.ntp.org 84.245.9.254Server hostname and resolved IP
s1Stratum 1 server (directly connected to a reference clock)
no-leapNo leap second pending

Important: Always use the -q flag when you only want to test connectivity. Without it, ntpdate will attempt to set your system clock, which can cause issues if another NTP daemon (chronyd or ntpd) is running.

Query Multiple Servers

# Query multiple servers at once and compare offsets
ntpdate -q 0.ubuntu.pool.ntp.org 1.ubuntu.pool.ntp.org 2.ubuntu.pool.ntp.org

Verbose Mode

# Use -d for debug output showing the full NTP packet exchange
ntpdate -d pool.ntp.org

This shows the complete NTP handshake including stratum, reference ID, root delay, root dispersion, and all candidate servers evaluated.

Method 2: Using ntpq (NTP Query Program)

If you are running the ntpd daemon (as opposed to chrony), ntpq provides detailed status information about your NTP peers.

Installation

sudo apt install ntp
# or for the more secure fork:
sudo apt install ntpsec

Query Local NTP Daemon Peers

# Show peer status of the local NTP daemon
ntpq -p

Example output:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp1.example.com .GPS.           1 u   34   64  377    1.234   -0.567   0.123
+ntp2.example.com .PPS.           1 u   12   64  377    2.456    0.234   0.089
-pool.ntp.org     192.168.1.1     2 u   45   64  377   15.789   -1.234   0.456

Understanding the Tally Codes

The first character on each line indicates the peer’s status:

SymbolMeaning
*Current sync source — the server your clock is synchronized to
+Candidate — acceptable server, ready to be selected if the current source fails
-Outlier — server rejected by the selection algorithm
xDesignated falseticker — server’s time is considered unreliable
.Culled from the candidate list (too far away or too unreliable)
(space)Rejected or not yet reached

Column Descriptions

ColumnDescription
remoteNTP server hostname or IP
refidServer’s reference source (e.g., .GPS., .PPS., or IP of its upstream)
stStratum (1 = directly connected to reference clock, 2-15 = downstream)
whenSeconds since last poll
pollPolling interval in seconds
reachReachability register (octal) — 377 means the last 8 polls all succeeded
delayRound-trip delay in milliseconds
offsetTime offset from server in milliseconds
jitterDispersion/variability of the offset

Query a Remote NTP Server

# Query a remote server directly (not just the local daemon)
ntpq -p 10.0.1.5

Check Association Details

# Show detailed association information
ntpq -c associations

# Show detailed peer variables for a specific association
ntpq -c "rv 0"

Method 3: Using chronyc (Chrony Client)

Chrony is the default NTP implementation on modern Ubuntu (18.04+). It replaces ntpd and uses the chronyc command-line tool for monitoring and management.

Installation

# Usually pre-installed on Ubuntu 18.04+
sudo apt install chrony

Check Synchronization Sources

chronyc sources

Example output:

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* ntp1.example.com              1   6   377    23   -567us[ -234us] +/-  1234us
^+ ntp2.example.com              1   6   377    45   +234us[ +567us] +/-  2345us
^- pool.ntp.org                  2   6   377    12  -1234us[-1567us] +/- 15678us

The tally codes for chrony:

SymbolMeaning
^*Current best source (synchronized)
^+Acceptable source (combined with the best)
^-Excluded by the combining algorithm
^?Connectivity lost or not yet resolved
^xDesignated falseticker

Detailed Source Statistics

chronyc sourcestats

This shows polling rate, frequency skew, and estimated offset stability for each source.

Check Tracking Information

chronyc tracking

Example output:

Reference ID    : 0A000105 (ntp1.example.com)
Stratum         : 2
Ref time (UTC)  : Mon Dec 16 22:00:01 2024
System time     : 0.000000234 seconds fast of NTP time
Last offset     : -0.000000567 seconds
RMS offset      : 0.000001234 seconds
Frequency       : 1.234 ppm slow
Residual freq   : -0.001 ppm
Skew            : 0.012 ppm
Root delay      : 0.001234567 seconds
Root dispersion : 0.000123456 seconds
Update interval : 64.0 seconds
Leap status     : Normal

Key fields to check:

  • System time: How far off your clock is from NTP time (should be sub-millisecond).
  • Stratum: Your machine’s stratum (server’s stratum + 1).
  • Leap status: Should be “Normal”. “Not synchronized” indicates a problem.

Test a Specific NTP Server with Chrony

To temporarily add and test a new NTP server:

# Add a server for testing
sudo chronyc add server 10.0.1.5

# Force an immediate poll
sudo chronyc burst 4/4

# Check the results
chronyc sources

Method 4: Using timedatectl (systemd)

Modern Ubuntu uses systemd-timesyncd as a lightweight SNTP client. You can check its status with timedatectl:

timedatectl status

Example output:

               Local time: Mon 2024-12-16 22:05:30 UTC
           Universal time: Mon 2024-12-16 22:05:30 UTC
                 RTC time: Mon 2024-12-16 22:05:30
                Time zone: UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Key indicators:

  • System clock synchronized: yes — NTP is working.
  • NTP service: active — The NTP daemon/client is running.

Check systemd-timesyncd Status

timedatectl timesync-status

Example output:

       Server: 91.189.94.4 (ntp.ubuntu.com)
Poll interval: 34min 8s (min: 32s; max: 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 2
    Reference: 11FD4D4C
    Precision: 1us (-24)
Root distance: 26.579ms (max: 5s)
       Offset: +2.564ms
        Delay: 163.563ms
       Jitter: 2.273ms
 Packet count: 7

Configure systemd-timesyncd NTP Servers

# Edit the timesyncd configuration
sudo nano /etc/systemd/timesyncd.conf
[Time]
NTP=10.0.1.5 10.0.1.6
FallbackNTP=ntp.ubuntu.com 0.ubuntu.pool.ntp.org
# Restart the service
sudo systemctl restart systemd-timesyncd

# Verify the new configuration
timedatectl timesync-status

Firewall Configuration

NTP uses UDP port 123. If a firewall is blocking this port, NTP queries will time out silently.

UFW (Ubuntu’s Default Firewall)

# Allow outbound NTP (client)
sudo ufw allow out 123/udp

# Allow inbound NTP (if this machine is an NTP server)
sudo ufw allow in 123/udp

# Verify the rules
sudo ufw status verbose

iptables

# Allow outbound NTP queries
sudo iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
sudo iptables -A INPUT -p udp --sport 123 -j ACCEPT

# If this machine is an NTP server, allow inbound
sudo iptables -A INPUT -p udp --dport 123 -j ACCEPT
sudo iptables -A OUTPUT -p udp --sport 123 -j ACCEPT

Testing Connectivity with nc (Netcat)

To verify that UDP port 123 is reachable before even trying NTP tools:

# Test UDP port 123 connectivity
nc -zuv 10.0.1.5 123

If the port is open, you will see Connection to 10.0.1.5 123 port [udp/ntp] succeeded!.

Troubleshooting Common Issues

Problem: ntpdate Returns “no server suitable for synchronization found”

Causes:

  • The NTP server is not running or not reachable.
  • A firewall is blocking UDP port 123.
  • DNS resolution is failing for the server hostname.

Steps:

# 1. Verify DNS resolution
dig +short ntp.internal.example.com

# 2. Test UDP port 123 connectivity
nc -zuv 10.0.1.5 123

# 3. Try with the -d flag for debug info
ntpdate -d 10.0.1.5

# 4. Check if another NTP daemon is binding port 123
sudo ss -ulnp | grep 123

Problem: chronyc Shows “Not synchronized” or ”^?” for All Sources

Causes:

  • The chrony daemon is not running.
  • All configured NTP servers are unreachable.
  • The system just booted and has not had time to synchronize yet.

Steps:

# 1. Check chrony daemon status
sudo systemctl status chronyd

# 2. Restart chrony
sudo systemctl restart chronyd

# 3. Force an immediate sync attempt
sudo chronyc makestep

# 4. Check sources again after 30 seconds
sleep 30 && chronyc sources

Problem: Large Time Offset (More Than 1000 Seconds)

If your system clock is off by more than ~17 minutes, ntpd will refuse to adjust it (by design, to prevent jumps). Chrony is more lenient but may still take time.

# Force an immediate time step with chrony
sudo chronyc makestep

# Or use ntpdate to do a one-time sync (stop ntpd first)
sudo systemctl stop ntp
sudo ntpdate -b pool.ntp.org
sudo systemctl start ntp

Problem: Time Drifts After Initial Sync

  • Check that the NTP daemon is actually running continuously: systemctl status chronyd or systemctl status ntp.
  • Verify the polling interval is not too long: chronyc sourcestats.
  • On virtual machines, disable hypervisor time synchronization if it conflicts with NTP. For VMware: vmware-toolbox-cmd timesync disable.

Comparing NTP Tools on Ubuntu

Featurentpdatentpq (ntpd)chronyc (chrony)timedatectl (systemd)
One-shot queryYesNoNoNo
Continuous syncNoYesYesYes (SNTP)
Detailed peer infoLimitedYesYesLimited
Default on Ubuntu 22.04+No (manual install)No (manual install)YesYes
Best forQuick testingServers running ntpdModern Ubuntu systemsBasic status checks

Summary

Testing NTP connectivity from an Ubuntu client can be done with several tools, each suited to different scenarios. Use ntpdate -q for quick one-shot verification, chronyc sources for monitoring chrony’s ongoing synchronization, ntpq -p if you are running the classic ntpd daemon, and timedatectl for a high-level systemd status check. Always verify that UDP port 123 is open on any firewalls between the client and server, and use debug flags (-d for ntpdate, sourcestats for chronyc) when troubleshooting connectivity failures.