[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