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
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
