[ntp:questions] NTP request retry?

Brian Utterback brian.utterback at oracle.com
Mon Jan 27 21:48:11 UTC 2014

On 1/26/2014 2:08 PM, Rob wrote:
> On a very quiet network, I observe that ntpd sometimes has a very
> high loss rate: reach is 6, for example.
> When using "ping" or any other protocol, no packet loss at all is
> observed.
> My hypothesis is that the ARP entry for the NTP server has timed out,
> and when ARP has to resolve an entry in some implementations the first
> packet is always lost (it is not cached pending a reply).
> When the cycle is 1024 seconds, the ARP entry has again timed out the
> next poll cycle and the issue is the same.
> Is there a way, short of switching to burst mode, to make ntpd retry
> a request when no reply is received e.g. within a second?
> It should only retry when there is no reply, and not more than e.g.
> 3 times (when still no reply it should simply wait for the next poll
> cycle)

I don't know about lost packets. It seems to me that dropping the packet 
that triggered an ARP request is not very robust, in fact it is down 
right fragile. Are you sure that there really are such implementations?

On the other hand, I have definitely observed that phenomenon as a 
source of asymmetric round trip time. The outgoing request packet gets 
delayed for ARP request and reply at each hop, but the return packet has 
no such delay. Quite a while ago I suggested a special burst mode where 
two packets were sent, one shortly after the other and the first one 
would be ignored. Dr. Mills said that the first would generally be 
ignored because of the longer round trip time (delay), but I thought 
that treating the first packet as a throw away would be better because 
otherwise you end up with half the number of "good" samples in the 
billboard. Anyway, nothing every came of the discussion.

Brian Utterback

More information about the questions mailing list