Host A
is probably making use of 802.11 Power Save mode, where it turns its receiver off between bursts of traffic and lets the AP queue up packets for it until it wakes its receiver up the next time, at which time it checks in with the AP to get its queued packets, and processes them.
Most vendors implement 802.11 Power Save in a way that they keep the receiver awake while it seems like a burst of traffic is going on, and then put it to sleep when there has been, say, a beacon interval (~100ms) without any traffic sent or received.
So when A transmits a ping to B, B is always awake and gets its response back within 5ms, before A puts its receiver to sleep.
But when B transmits a ping to A, A's receiver is asleep already, and doesn't wake up for a few beacon intervals, and then wakes up, gets B's queued-up ping request from the AP, and then sends its ping response to B. Since the ping
command sends pings once-per-second by default, A's receiver often has plenty of time (several 100ms beacon intervals) to go to sleep before it gets the next ping request.
The exact timing of how long A sleeps, and how that lines up with the once-per-second pings, could cause a "phasing effect" or kind of periodical oscillation in ping times. Also, other traffic that A needed to deal with may keep A awake longer sometimes, resulting in shorter ping times sometimes.
Yes, after some experimenting, I think this is almost certainly what is going on! If I set the ping interval short enough, the problem goes away entirely. Unfortunately, the driver doesn't seem to support disabling power management so I guess I'll have to live with it for now. But at least now I know the cause. Thank you so much! – Owen – 2014-02-13T22:25:01.583
So, what I did to "fix" the problem was, from host A,
ping -i 0.1 B
and have that running constantly. A tad wasteful, but ssh is usable now. – Owen – 2014-02-13T22:30:26.297Pinging the AP itself (or something on the wired network that the AP connects to) would be less wasteful of airtime. Using some other tool to send tiny UDP datagrams to the "discard" port (port 9) of the AP or another machine on the wired network would be even better. Of course as you say, fixing the driver would be best. – Spiff – 2014-02-14T02:02:00.077