[ntp:questions] NTP request retry?

detha detha at foad.co.za
Wed Jan 29 19:39:09 UTC 2014


On Wed, 29 Jan 2014 17:56:04 +0000, Rob wrote:

> detha <detha at foad.co.za> wrote:

>> If keeping the link open with a ping helps, second step is to determine
>> what times out. Run a ping from somewhere else to the server, or from
>> the client to somewhere else. If running a ping from the client to
>> somewhere else makes the problem go away, it could be some power-saving
>> thing getting in the way. If not, it /might/ be ARP; time to start
>> running tcpdump on both client and server, and compare the captures.
> 
> I did that before.  I am not sure what will happen when a client tries to
> send a query and has no ARP entry.  Will the send appear in the tcpdump or
> not.  I'm inclined to think not, because tcpdump has the option to display
> the full header including MAC address and this is not known at the time. 
> So probably tcpdump logs only when ARP has completed. In my trace I saw
> unanswered queries, so it could be that ARP was not the cause.  The
> tcpdump on the server did not show the corresponding incoming queries.

Tcpdump will capture the ARP traffic fine. The request has a destination
MAC of ff:ff:ff:ff:ff:ff, i.e. broadcast, the reply normally goes to the
MAC address of the requester. If running a 'full' capture on the server
for the entire test cycle generates too big a file, you can filter on
'ether host aa:bb:cc:dd:ee:ff' for the mac address of the client.

>> When troubleshooting this type of thing, don't forget switches. I've
>> recently encountered so-called 'green' switches that shut down ports
>> with no traffic, and occasionally forget to turn them on again.
> 
> The switch is oldish and probably not affected by this.  Also, the WiFi is
> used by other clients so its port will remain primed.  So is the server. 
> If this problem occurs, it should only affect the wired client.
> 
> The only thing the two clients have in common is that they both are a
> Raspberry Pi.  They run different Linux distributions, different kernels,
> different interfaces (one wired one usb-WiFi).  Ok the NTP version is also
> the same (4.2.6p5).
> And they both are mostly idle.
> Even if there is a sleep mode in the ethernet driver, and it has a bug
> that causes the first packet transmitted from sleep mode to be lost (this
> could be inferred from another reply in the thread), I would be surprised
> if the WiFi would be affected exactly the same way. And I am used to wacky
> performance from WiFi, but not from wired 100Mbit ethernet.

What distribution and kernel are you running on the wired one? I've got a
spare raspberry somewhere, would be interesting to see if I can reproduce
this.

-d



More information about the questions mailing list