5

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:

A-B-A:

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

B-A-B:

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?

2 Answers 2

6

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.

4
  • 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, 2014 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, 2014 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, 2014 at 2:02
  • Oh my god I have been trying to fix the slow SSH connection to a server on my LAN forever and this finally solved it. For future visitors, you can find instructions to turn off power saving on Linux here
    – jmracek
    Apr 24, 2020 at 1:29
0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .