On Mon, Jan 18, 2010 at 04:24:52PM -0500, Michael Breuer wrote:

On 1/18/2010 4:00 PM, Stephen Hemminger wrote:

quoted

On Mon, 18 Jan 2010 15:56:45 -0500
Michael Breuer[off-list ref]  wrote:

quoted

quoted

quoted

2. The dropped tx packet (DHCP) is a bit harder to recreate, but it
still happens.

You might want to use tc filter rule to set priority of DHCP packets
higher. This would cause them to be in a separate queue and eliminate
the problem.

Ok - for fun, tried that - no change. Not sure I see why this might
be a factor. The packet loss happens when TX load is low and RX
high.
Also,  packets only being dropped if traversing a router vs.to  the
router itself.  Keep in mind that pings to the router did not lose
packets, pings through the router lost packets. The router was not
under load (traffic is being generated from a device connected via
the 1Gb switch, not the wifi router), and tcpdump on the router
input port shows the pings to the router, but not the ones through
the router.

One added note, when I just tried this, the test data ended while
the packet loss was occurring. The DHCPOFFER packet loss did not
clear until about a minute after the throughput abated. I really
think something is getting hosed, and I'd but some weird interaction
with the arp logic high on the list of suspects. Not sure what else
would be a factor when looking at the extra hop on the same subnet.

Good point! Actually, IIRC, your setup might be a problem: you seem
to have two switches on the path (I guess the router is a bridge for
these wireless), so I wonder if it's not something between them.

Jarek P.