Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have two computers, both running Linux Mint Petra (one 32 bit, one 64 bit). Call them A and B. They are on a wireless network.

The RTTs are strangely asymmetric:


user@A $ ping B
~~ 5ms, consistent times ~~


user@B $ ping A
~~ 100-2000ms, wildly inconsistent times ~~

I am at a loss to think of a mechanism. Clearly both network interfaces are involved in either A-B-A or B-A-B so I don't suspect a driver issue, but you never know. Is there some configuration that could be related that I could look for? Is the problem more likely to be on A's side or B's side?

share|improve this question
up vote 1 down vote accepted

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.

share|improve this answer
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 Feb 13 '14 at 22:25
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 Feb 13 '14 at 22:30
Pinging 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 Feb 14 '14 at 2:02

The issue is clearly on A's side, could be a processing time issue, A pings B which responds almost instantly sending a packet back, where as B pings A which may be under heavy load and takes more time to send a reply packet.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.