Chrony is a flexible and modern implementation of the Network Time Protocol (NTP). It is designed to synchronize the system clock with NTP servers, reference clocks, or manual input with high accuracy. It excels in environments where the connection to the time source is intermittent or when the system clock is frequently interrupted (such as virtual machines)
chrony officially replaced the traditional ntpd (NTP Daemon, provided by the legacy ntp package) as the default time synchronization service starting in RHEL 7.
| Feature | Chrony (chronyd) | ntpd (Legacy) |
| Clock Correction | Slewing Only (Default): Adjusts the clock gradually and precisely. Can handle frequent clock interruptions without losing accuracy. | Slewing & Stepping: Slews for small adjustments but uses disruptive stepping (jumping the time) for large offsets, which can impact applications. |
| Start-Up Time | Fast: Uses makestep at startup to quickly correct large initial errors, then immediately begins slewing. | Slow: Waits for the clock to slowly adjust, often taking longer to achieve synchronization. |
| Network | Better for Intermittent Connections: Handles situations where the server connection is lost or the clock frequently changes (e.g., suspend/resume). | Requires Constant Connectivity: Struggles with intermittent network loss and frequent system time changes. |
| Resource Use | Low: Very small memory footprint and fewer CPU cycles required. | Moderate: Larger memory and CPU consumption. |
| Security | More Secure: Designed with security in mind, often running with fewer privileges. | Older Codebase: Has had more vulnerabilities over the years. |
Chrony Basic Commands
| Command | Purpose | Notes |
chronyc sourcestats -v | Shows long-term source stability. Displays long-term statistics for each source, including clock drift and frequency estimation. | Useful for spotting an unstable NTP server or bad hardware clock. |
chronyc clients | Shows who is using your server. If you are configured as an NTP server, this command lists the hosts that are currently querying you for time (requires the ntpserver directive in your config). | Useful for confirming if your NetApp LIF is actually reaching your RHEL box and making a request. |
chronyc makestep | Forces an immediate time correction. If your clock is severely off (more than a few minutes), this commands the daemon to immediately jump the clock to the correct time, instead of gradually slewing it. | Use with Caution! Sudden time jumps can affect applications like databases. |
chronyc ntpdata $IP | This performs a one-time query to the specified server, simulating how the client would communicate with it. | $IP seems to need to exist as source in chronyd.conf |
chronyc add server <IP> | Adds a server dynamically. Adds a new NTP server to the running configuration without restarting the service. | Changes made this way are not permanent and will be lost if chronyd restarts. |
Service Configuration File
The main configuration file for chronyd is /etc/chrony.conf
After any config file change, you need to restart the chronyd service
# systemctl restart chronyShow Chrony Clients
Running “chronyc -n clients -v” will show you the clients currently using a chrony server as a timesource
~# chronyc -n clients -v
Hostname NTP Drop Int IntL Last Cmd Drop Int Last
===============================================================================
10.1.10.10 59 0 9 - 115 0 0 - -
10.1.10.21 29 0 9 - 49 0 0 - -
10.1.10.49 44 0 7 - 117 0 0 - -
10.1.10.45 50 0 6 - 10 0 0 - -
10.1.10.13 36 0 7 - 56 0 0 - -
10.1.10.18 39 0 6 - 20 0 0 - -
10.1.10.20 37 0 7 - 27 0 0 - -
10.1.10.15 35 0 7 - 54 0 0 - -
10.1.10.50 24 0 7 - 160 0 0 - -
Below is a breakdown of the command output
Hostname
- The IP address (or hostname) of each NTP client querying this Chrony server.
- In this case: multiple clients in the
10.1.10.0/24subnet.
NTP
- Total number of valid NTP packets received from that client.
- This is cumulative since Chrony started.
- Example:
10.1.10.10 → 59. Means this client has successfully sent 59 NTP requests.
What to expect
- Steadily increasing numbers = healthy client
- Very low numbers = new client or infrequent polling
Drop (NTP side)
- Number of NTP packets dropped from this client.
- Drops occur if packets are malformed, too frequent, or violate limits.
Int
- Current polling interval (log2 seconds).
- Chrony uses exponential polling.
| Int | Actual Interval |
|---|---|
| 6 | 64 seconds |
| 7 | 128 seconds |
| 8 | 256 seconds |
| 9 | 512 seconds |
IntL
- Previous polling interval
-means no recent change
Last (NTP side)
- Seconds since the last NTP packet was received from that client.
What to expect
- Should generally be less than or near the polling interval
- Larger numbers are fine if the client polls slowly
Command (Cmd) columns
These relate to Chrony command/control packets, not time sync traffic.
Cmd
- Number of chronyc command requests received from that client
0means the client is only syncing time, not issuing admin commands
Drop (Cmd)
- Dropped command packets
0is ideal
Int (Cmd)
- Poll interval for command packets
-means none used
Last (Cmd)
- Time since last command packet
-means no commands received
Show Chrony Sources
# chronyc sources -v
.-- Source mode '^' = server, '=' = peer, '#' = local clock.
/ .- Source state '*' = current best, '+' = combined, '-' = not combined,
| / 'x' = may be in error, '~' = too variable, '?' = unusable.
|| .- xxxx [ yyyy ] +/- zzzz
|| Reachability register (octal) -. | xxxx = adjusted offset,
|| Log2(Polling interval) --. | | yyyy = measured offset,
|| \ | | zzzz = estimated error.
|| | | \
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^- prod-ntp-3.ntp4.ps5.cano> 2 10 377 625 +1096us[+1096us] +/- 49ms
^- prod-ntp-4.ntp4.ps5.cano> 2 10 377 504 +144us[ +144us] +/- 51ms
^- alphyn.canonical.com 2 10 377 756 +619us[ +804us] +/- 40ms
^- prod-ntp-3.ntp1.ps5.cano> 2 10 377 759 +1352us[+1537us] +/- 51ms
^+ chi2.us.ntp.li 2 10 377 552 -1204us[-1204us] +/- 20ms
^- ovh.maxhost.io 2 10 377 628 -3688us[-3688us] +/- 58ms
^* atl-ntp2-0.mattnordhoffd> 2 10 377 741 +1002us[+1188us] +/- 7918us
^- 2a01:7e04::2000:5dff:fe1> 4 10 377 739 -1535us[-1535us] +/- 49ms
MS (Mode / State)
^= NTP server== peer#= local reference clock
State indicator:
*= current best source (in use)+= combined (used with others)-= selectable but not usedx= faulty~= too variable?= unreachable
Stratum
- Distance from a reference clock (lower is better)
- GPS/PPS = stratum 0
- Typical upstream servers = stratum 1–3
Poll
- Polling interval (log2 seconds)
| Poll | Interval |
|---|---|
| 6 | 64 seconds |
| 7 | 128 seconds |
| 8 | 256 seconds |
Reach
- Octal reachability register (last 8 polls)
377(octal) = perfect reachability- Lower values = packet loss or intermittent connectivity
LastRx
- Seconds since last successful response
- First value = adjusted offset
- Bracketed value = raw measured offset
+/-= estimated error margin
Units:
ns= nanosecondsus= microsecondsms= milliseconds
Show Source Stats
# chronyc sourcestats -v
.- Number of sample points in measurement set.
/ .- Number of residual runs with same sign.
| / .- Length of measurement set (time).
| | / .- Est. clock freq error (ppm).
| | | / .- Est. error in freq.
| | | | / .- Est. offset.
| | | | | | On the -.
| | | | | | samples. \
| | | | | | |
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
prod-ntp-3.ntp4.ps5.cano> 31 14 106m +0.120 0.212 +1317us 596us
prod-ntp-4.ntp4.ps5.cano> 33 19 108m -0.021 0.542 +316us 1235us
alphyn.canonical.com 33 14 104m -0.036 0.234 +594us 635us
prod-ntp-3.ntp1.ps5.cano> 33 19 104m +0.096 0.342 +1156us 761us
chi2.us.ntp.li 33 18 107m -0.087 0.341 -1596us 873us
ovh.maxhost.io 31 14 96m +0.147 0.382 -2735us 765us
atl-ntp2-0.mattnordhoffd> 33 16 104m +0.083 0.331 +762us 889us
2a01:7e04::2000:5dff:fe1> 33 19 104m -0.284 0.513 -1432us 1236us
This shows:
- Average offset
- Standard deviation (jitter)
- Frequency correction
- Stability over time
Show Selected Source
chronyc tracking
Reference ID : EE1C3393 (atl-ntp2-0.mattnordhoffdns.net)
Stratum : 3
Ref time (UTC) : Fri Dec 26 20:54:37 2025
System time : 0.000375564 seconds fast of NTP time
Last offset : +0.000185856 seconds
RMS offset : 0.000497939 seconds
Frequency : 33.487 ppm slow
Residual freq : +0.008 ppm
Skew : 0.299 ppm
Root delay : 0.014126181 seconds
Root dispersion : 0.002563612 seconds
Update interval : 1033.8 seconds
Leap status : Normal
Reference ID
- The active NTP source currently disciplining your clock.
EE1C3393is the hexadecimal reference identifier.- The hostname confirms DNS resolution of the upstream server.
✔ This tells you exactly which server is in use.
Stratum
- Indicates the distance from a reference clock.
- Stratum hierarchy:
- 0 → GPS / atomic clock (not directly used)
- 1 → Directly connected to stratum 0
- 2 → Syncing from stratum 1
- 3 → Syncing from stratum 2
✔ Stratum 3 is normal and acceptable for internet-sourced NTP.
Ref time (UTC)
- Timestamp of the last successful synchronization sample.
- Expressed in UTC.
✔ Confirms recent and valid sync.
System time
- Your local clock is ahead of true NTP time by ~0.38 ms.
- Chrony is actively correcting this.
✔ Sub-millisecond offset is excellent.
Last offset
- Offset measured during the most recent update.
- Positive = system clock was fast.
✔ Very small deviation (~0.19 ms).
RMS offset
- Root Mean Square of offsets over recent samples.
- Represents overall synchronization quality.
✔ <1 ms RMS is very good for non-GPS NTP.
Frequency
- How far your system clock naturally drifts without correction.
ppm= parts per million.- “Slow” means your hardware clock loses ~33 µs per second.
✔ Completely normal for commodity hardware.
Residual freq
- Remaining frequency error after corrections.
- Shows how well Chrony has tuned the clock.
✔ Near-zero = excellent convergence.
Skew
0.299 ppm
- Estimated uncertainty in frequency measurement.
- Lower = higher confidence.
✔ <1 ppm is strong stability.
Root delay
0.014126181 seconds
- Total round-trip delay to the reference clock.
- Includes network latency through the NTP chain.
✔ ~14 ms is expected for internet NTP.
Root dispersion
- Estimated maximum error relative to true time.
- Accumulates over time since last sync.
✔ ~2.5 ms is very good.
Update interval
- Time between Chrony updates (~17 minutes).
- Increases as clock stability improves.
✔ Indicates a stable and trusted source.
Leap status
- No leap second pending or in progress.
✔ Required for accurate timekeeping.
Pingback: Setup NTP Server on Ubuntu 22.04 with GPS Receiver Guide