On Wed, 29 Jan 2014 17:56:04 +0000, Rob wrote: > detha <[email protected]> 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 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
