Chrony "root dispersion" keeps rising steadly over time, despite accurate time sync

Question

I have a Debian 10 system that uses chronyd to keep its clock in sync. The config is pretty simple:

pool 2.debian.pool.ntp.org offline iburst

bindaddress ::1
bindaddress 127.0.0.1
bindcmdaddress 127.0.0.1

allow 127
deny

keyfile /etc/chrony/chrony.keys
driftfile /var/lib/chrony/chrony.drift
logdir /var/log/chrony
log tracking measurements statistics

maxupdateskew 100.0

directive.
hwclockfile /etc/adjtime

rtcsync
makestep 1 3

It's happily synced:

# chronyc sources
210 Number of sources = 4
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^- time.panq.nl                  2   6     0   83h  -1247us[-1191us] +/-   26ms
^* time.cloudflare.com           3   6     0   83h  +1343ns[  +58us] +/- 2669us
^- metronoom.dmz.cs.uu.nl        2   6     0   83h    -63us[  -63us] +/-   25ms
^- .                             3   6     0   83h  +2171us[+2171us] +/-   64ms

However, the "root dispersion" keeps rising steadily. From What is NTP dispersion and how do I control it? it seems this is a measure of the maximum error in the upstream server's clock. It's rising quite slowly, the process has been up for about 70 hours or so and it stands at 22.5s. I do know from experience that this will keep rising until chronyd restarts.

# chronyc tracking
Reference ID    : E1FE1EBE (time.cloudflare.com)
Stratum         : 4
Ref time (UTC)  : Sun Jan 26 23:19:16 2020
System time     : 0.000000005 seconds fast of NTP time
Last offset     : +0.000056495 seconds
RMS offset      : 0.000056495 seconds
Frequency       : 79.909 ppm slow
Residual freq   : +17.510 ppm
Skew            : 56.420 ppm
Root delay      : 0.004632703 seconds
Root dispersion : 22.573289871 seconds
Update interval : 1.6 seconds
Leap status     : Normal

This seems unusual to me. I have a load of other systems that sync time with a Stratum 1 server where the root dispersion is low and constant. I don't think I'm doing anything odd on the config, and the idea that the "maximum error in the upstream clock" rises steadily smells a bit off.

Is this normal?

Answer 1

It's happily synced

No, it is not. Although, it will adjust for known drift better than not running any NTP.

Reach 0 means it has not received a packet for a while. LastRx 83h indicates the last good packet was three and a half days ago.

Unlikely that a working Internet connection would be unroutable to both Cloudflare and some pool servers. Check any firewall for 123/udp.