How to interpret small poll, large lastRx and maximum reach value in `chronyc sources` report?

I'm monitoring a chrony client using chronyc sources called every second.

This command reports several values including

Poll - This shows the rate at which the source is being polled, as a base-2 logarithm of the interval in seconds. Thus, a value of 6 would indicate that a measurement is being made every 64 seconds. chronyd automatically varies the polling rate in response to prevailing conditions.

Reach - This shows the source’s reachability register printed as an octal number. The register has 8 bits and is updated on every received or missed packet from the source. A value of 377 indicates that a valid reply was received for all from the last eight transmissions.

LastRx - This column shows how long ago the last sample was received from the source. This is normally in seconds. The letters m, h, d or y indicate minutes, hours, days, or years.

From the chronyc Documentation

I've used the chrony configuration to set the poll rate to 4 seconds. Most of the time, I observe the lastRx column (how long ago the last sample was received from the source) climb from 0 to three and then drop down to zero again as the next sample is received as expected. For example, here's part of the table I built from the output

Timestamp                IP address    Poll Reach LastRx
==========================================================================
'2023-02-02 10:02:58'   '10.0.0.102'    2   377   0
'2023-02-02 10:02:59'   '10.0.0.102'    2   377   1
'2023-02-02 10:03:00'   '10.0.0.102'    2   377   2
'2023-02-02 10:03:02'   '10.0.0.102'    2   377   4
'2023-02-02 10:03:03'   '10.0.0.102'    2   377   0
'2023-02-02 10:03:04'   '10.0.0.102'    2   377   1
...

However, sometimes, LastRx starts to climb and climbs far above 4. I would expect this to happen if connectivity to the time server were lost. What puzzles me, is that during these periods, the reach value is still 377, indicating that all packets are being received, and the poll rate is still being reported as 4 seconds (2^2).

Timestamp                IP address    Poll Reach LastRx
==========================================================================
'2023-02-02 09:59:17'   '10.0.0.102'    2   377   109
'2023-02-02 09:59:18'   '10.0.0.102'    2   377   110
'2023-02-02 09:59:19'   '10.0.0.102'    2   377   111
'2023-02-02 09:59:21'   '10.0.0.102'    2   377   112
'2023-02-02 09:59:22'   '10.0.0.102'    2   377   113
'2023-02-02 09:59:23'   '10.0.0.102'    2   377   114 

How can it be 114 seconds since chrony last received a packet, while polling for new packets every 4 seconds and still report that every packet has been received? What's going on?

Edit:

Here are the configurations I'm using.

#server 10.0.0.102

makestep 1.0 3                                                               
driftfile /var/lib/chrony/drift                                              
rtcsync                                                                      
allow 10.0.0                                                                 
local stratum 8                                                              
manual                                                                       
logdir /var/log/chrony  

#client 10.0.0.101

server 10.0.0.102 iburst maxpoll 2 minpoll 1 prefer
maxdistance 1000000000
makestep 1.0 3
driftfile /var/lib/chrony/drift
logdir /var/log/chrony

These configurations appear to be reasonable for a basic Chrony setup. However, it's worth noting that the specific values you use for the maxpoll, minpoll, and maxdistance settings can affect the accuracy and stability of the time synchronization, so you may want to adjust these values based on your specific requirements and network conditions.

In the case you describe, it is possible that the server is sending packets, but they are being lost or delayed in transit, which could explain why the last received packet time is much later than the polling interval.

Chrony reports that every packet has been received because it is based on the assumption that all packets sent by the server are received by the client. However, in reality, packets can be lost or delayed due to network issues or other factors.

To investigate the issue further, you can check the output of the chronyc tracking command to see if the system clock is being adjusted based on the server's responses, and also check the network connectivity between the client and the server.