<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Hal,</p>
<p>The ARP comment referred to another ntp.conf comment higher up:</p>
<pre># *** NOTE: by default, the ARP cache flushes after 60 seconds. If so, use maxpoll 5 ***
# *** I modified the ARP flush on rPi to 65sec, so maxpoll 6 (64s) is should be OK ***
# /etc/sysctl.d/ net.ipv4.neigh.default.gc_stale_time = 65
</pre>
<p>It was inspired from my interpretation of <a
moz-do-not-send="true"
href="https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html#_arp_is_the_sound_of_your_server_choking">https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html#_arp_is_the_sound_of_your_server_choking:</a><br>
</p>
<p>
<blockquote type="cite">
<div class="sect2">
<h3 id="_arp_is_the_sound_of_your_server_choking">ARP is the
sound of your server choking</h3>
<div class="paragraph">
<p>By default ntpd and chronyd poll remote servers every 64
seconds. This
is an unfortunate choice. Linux by default only keeps an
ARP table
entry for 60 seconds, anytime thereafter it may be
flushed.</p>
</div>
<div class="paragraph">
<p>If the ARP table has flushed the entry for a remote peer
or server then
when the NTP server sends a request to the remote server
an entire ARP
cycle will be added to the NTP packet round trip time
(RTT). This will
throw off the time measurements to servers on the local
lan.</p>
</div>
<div class="paragraph">
<p>On a RaspberryPi ARP has been shown to impact the remote
offset by up to
600 uSec in some rare cases.</p>
</div>
<div class="paragraph">
<p>The solution is the same for both ntpd and chronyd, add
the "maxpoll 5"
command to any 'server" or "peer directive. This will
cause the maximum
polling period to be 32 seconds, well under the 60 second
ARP timeout.</p>
</div>
</div>
</blockquote>
My understanding is that after <i>net.ipv4.neigh.default.gc_stale_time</i>'s
default of 60 seconds, the ARP cache entry <i>might </i>be
flushed. If the poll time is 64s and the cache has been flushed,
an ARP request has to be sent and replied to by my local router
before the actual NTP packet can be sent. This would introduce
delays, and maybe this asymmetric RTT delay could induce
additional error every time the server is polled. By limiting the
poll interval to something less than <i>net.ipv4.neigh.default.gc_stale_time</i>,
this extra RTT delay can be avoided. <br>
</p>
<p>My Pi is not currently dedicated to time duty, and there is a
constant flow of packets, so I might not need it, but from what I
understand, it is prudent. I'm not an ARP, Debian/Raspbian or NTP
expert, but I did dig a bit in Ethernet packets in the past. It's
only a personal interpretation of the voodoo of it all, so I could
be wrong.</p>
<p>Martin<br>
<i></i></p>
<div class="moz-cite-prefix">On 2020-03-21 02:04, Hal Murray wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20200321060446.EA5DA40605C@ip-64-139-1-69.sjc.megapath.net">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">server time.nrc.ca maxpoll 6 # For ARP reasons, set maxpoll 6 -> 64s
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
What's with the ARP comment? You aren't ARPing for that host but rather your
next hop router headed that way?
</pre>
</blockquote>
</body>
</html>