When working with time synchronization across mixed environments, NTP dispersion values can become particularly problematic in embedded systems. The case presented involves Ubuntu 14.04 servers (running ntpd 4.2.6p5) and BusyBox clients (with ntpclient 2010) showing dispersion values exceeding 1,000,000 microseconds - far beyond ntpclient's 65536 limit.

Dispersion in NTP represents the maximum error bound of a time source, accumulating from multiple factors:

• Server stratum level and clock precision
• Network jitter and asymmetric delays
• Clock drift accumulation since last synchronization
• Reference clock inaccuracies

In the observed case, the dispersion value of 1,216,163.1 microseconds suggests either:

1. The NTP server's reference clock is unstable
2. Network paths are introducing significant variability
3. The server configuration improperly handles dispersion calculations

First, verify the NTP server's time sources:

$ ntpq -c "rv 0 dispersion"
$ ntpq -c "as"

For the Ubuntu server acting as intermediary, check its synchronization quality:

$ ntpstat
$ ntpq -pn

The provided ntpq output shows concerning metrics:

• Multiple stratum 4 servers with offsets >100ms
• Jitter values consistently >300μs
• A stratum 1 server (.LOCL) suggesting it might be misconfigured

Modify /etc/ntp.conf on the Ubuntu server with these key parameters:

# Control dispersion growth
tinker dispersion 500
tinker panic 0

# Improve server selection
server 10.31.10.21 iburst minpoll 4 maxpoll 6 prefer
server 10.17.6.10 iburst minpoll 4 maxpoll 6

After changes, verify operation:

$ sudo service ntp restart
$ ntpq -c rv
$ ntpdc -c sysinfo

For the BusyBox ntpclient limitation, consider these approaches:

Option 1: Modify the ntpclient source (if possible) to handle larger dispersion values

// In ntpclient.c, find the dispersion check:
if (abs(disp) > 65536) {
    // Change to higher threshold or remove check
}

Option 2: Use a shell wrapper to filter responses:

#!/bin/sh
while true; do
    output=$(ntpclient -s -i 5 -h $SERVER 2>&1)
    if ! echo "$output" | grep -q "Dispersion too high"; then
        echo "$output"
        break
    fi
    sleep 1
done

Chrony Implementation: Chrony handles high dispersion scenarios better:

$ sudo apt-get install chrony
# /etc/chrony/chrony.conf
server 10.31.10.21 iburst
server 10.17.6.10 iburst
makestep 1.0 3
maxdistance 16.0

Direct Stratum 1 Access: Where possible, configure clients to use the same stratum 1 source as the Ubuntu server.

Implement continuous monitoring with:

$ ntpq -c "rv 0 rootdisp"
$ chronyc tracking | grep "Root dispersion"

For automated alerts, use this Nagios check:

#!/bin/bash
WARNING=1000
CRITICAL=5000

DISP=$(ntpq -c "rv 0 rootdisp" | awk -F= '{print $2}' | awk '{print $1}')

if (( $(echo "$DISP > $CRITICAL" | bc -l) )); then
    echo "CRITICAL: NTP dispersion $DISP μs"
    exit 2
elif (( $(echo "$DISP > $WARNING" | bc -l) )); then
    echo "WARNING: NTP dispersion $DISP μs"
    exit 1
else
    echo "OK: NTP dispersion $DISP μs"
    exit 0
fi

---

NTP dispersion represents the maximum error estimate in the time calculation, expressed in microseconds. It accumulates from several sources:

• Clock precision of each stratum server
• Network path instability
• System clock drift
• Time source authentication failures

In your case, the dispersion value 1,216,163.1 µs (≈1.2 seconds) exceeds ntpclient's hardcoded limit of 65,536 µs (0.065 sec). This indicates either:

1. The NTP servers have poor time synchronization themselves
2. Network conditions introduce excessive variability
3. Server configuration issues in the NTP hierarchy

Run these commands on your Ubuntu server to investigate the NTP sources:

# Check peer status with detailed metrics
ntpq -c "rv 0 dispersion" -pn

# Get NTP server health statistics
ntpstat -v

# Check kernel discipline status
ntptime

# Monitor real-time offset changes
ntpdc -c loopinfo

For the BusyBox clients, add verbose logging to ntpclient:

ntpclient -d -d -l 4 -h ntp-server-ip

The ntpq output shows potential issues:

• Stratum 5 server (10.17.162.249) has high offset (1381ms)
• Inconsistent delay values (0.366ms vs 29.586ms)
• Reference clock issues (.LOCL. indicates local clock)

Recommended ntp.conf adjustments:

# Increase dispersion ceiling
tinker dispersion 1000000

# Set stricter selection thresholds
tos maxdist 1
tos mindist 0.02

# Force better servers
server 10.31.10.21 iburst prefer
server 10.31.10.22 iburst

Chrony handles poor network conditions better. Sample chrony.conf:

server 10.31.10.21 iburst
server 10.31.10.22 iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
maxdistance 16.0
maxdelay 0.5
maxslewrate 1000

For the BusyBox limitation, consider:

# Patch ntpclient to increase dispersion threshold
--- ntpclient.c
+++ ntpclient.c
@@ -42,6 +42,6 @@
-#define MAXDISP 65536 /* 65.536 ms */
+#define MAXDISP 10000000 /* 10 seconds */

Or implement a wrapper script:

#!/bin/sh
for server in $NTP_SERVERS; do
  if ntpclient -h $server | grep -q "acceptable"; then
    exit 0
  fi
done
exit 1