NTS Time Server ntp.bollar.com

[Martin Boissonneault]

Hi Hal,

The ARP comment referred to another ntp.conf comment higher up:

# *** 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

It was inspired from my interpretation of 
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>

>
>       ARP is the sound of your server choking
>
> 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.
>
> 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.
>
> On a RaspberryPi ARP has been shown to impact the remote offset by up 
> to 600 uSec in some rare cases.
>
> 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.
>
My understanding is that after /net.ipv4.neigh.default.gc_stale_time/'s 
default of 60 seconds, the ARP cache entry /might /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 
/net.ipv4.neigh.default.gc_stale_time/, this extra RTT delay can be 
avoided.

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.

Martin
//

On 2020-03-21 02:04, Hal Murray wrote:
>> server time.nrc.ca 	maxpoll 6 	# For ARP reasons, set maxpoll 6 -> 64s
> What's with the ARP comment?  You aren't ARPing for that host but rather your
> next hop router headed that way?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/users/attachments/20200323/1f98d210/attachment.htm>