Ping, Pong, Sleepy Wireless Adapters

(This post covers some MacBook Pro wireless adapters. I’m not sure if other systems behave the same way.)

We had some latency spikes in a wireless LAN and I had to remotely diagnose it. On a quiet evening when there were less devices talking in the air, I decided to randomly pick some devices from the AP’s dashboard and ping them from a machine which had wired connection to the switch.

I got stable RTT’s from one client, but surprisingly unstable results from another one.

I quickly noticed that the client that had stable RTT’s was a Ubuntu laptop which I knew and had SSH access to. The other one was a Mac as the AP dashboard showed. It must be a MacBook Pro, I guess, as it’s the most common thing in that office. I increased ping frequency and tried several other Mac’s. Their RTT’s all showed oscillating patterns like this:

ping -i 0.1 [IP of a sleeping MacBook Pro]

It’s suggested that ping should only be used to check connectivity, and it alone is not appropriate for assessing latency, for the existence of QoS systems. But it was clear to me that neither the AP or the switch had QoS rules configured. And RTT to the Ubuntu laptop was always around 5 ms, so QoS should not be the one to blame. I’d say ping is the simplest, most accessible, yet effective tool to evaluate latency. There are more advanced tools like irtt, which needs you to have control on both ends.

I noticed people on the web talking about ping spikes on Mac caused by location services and WiFi scanning. But can they create such a beautiful pattern? I doubted.

Just sleepy, not sleeping

It occurred to me that the owners should have closed the lids of their MacBooks before going home. Why could I see them connected to the AP and ping them in the first place?

This reminded me of annoying things that had been happening to recent versions of macOS. While the MacBook is sleeping (with power adapter plugged in), some notifications would wake up the external display, and play loud sounds to wake up me in late nights. I don’t remember if I completely fixed this, but eventually I turned off Reminders sync on MacBooks.

So with power adapter plugged in, macOS tries to be smart, diligently getting things done even when you tell it to take a break.

But it does so with less power consumption, only transmitting data periodically as indicated here, although anecdotally. From the graph above, we can probably guess the sleep cycles are of 80-90 ms.

That’s a hypothesis. I tried to reproduce this at home, but didn’t get the same pattern. However when ping’ing a sleeping MacBook Pro I did see:

  • With power adapter, RTT was over 100ms, sometimes 400+ ms.
  • With battery power, it’s not reachable.

Still sleepy when awake

How does it perform when it’s awake?

I ran a ping to a MacBook Pro (~2015 model, Catalina, default energy saver settings) at home connected to the same wireless router (with AirDrop disabled, see later section):

ping -i 0.5 [a MacBook Pro]

This graph shows that it’s not that sober!

You may wonder why the curve flattened after 200 packets. That’s when I started ping’ing the gateway from the MacBook Pro, generating packets frequent enough to make its wireless adapter always active. I had to do it with 0.1 second intervals. Larger intervals were not so effective. As I tested, as long as the adapter detects a high enough frequency, it will keep active. E.g.:

  • Downloading a large file via HTTP – packets leaving (ACK’s) and arriving (data) the adapter frequently.
  • Ping’ed from other machines with 0.1 second intervals – packets arriving at the adapter frequently.

So even with power adapter connected, macOS tries to save energy and sleep the wireless adapter.

Packets leaving the system are never affected, though. Even you ping gateway with very large intervals, it shows stably low RTT’s.

Does it really hurt?

Obviously it hurts people who want to ping Mac’s to assess wireless latency, whether they’re sleeping or not.

But this is a clever power management mechanism, and should work well for personal computers. Flows are mostly interactive and there’s no delay when initiating requests even when the wireless adapter is idle. As long as the adapter isn’t idle for a long period (i.e. several hundred milliseconds), it won’t sleep and can receive/ACK packets instantaneously.

However there can be some cases where it could be a potential problem. For example, in a long-haul small window TCP connection, there might be gaps between waves (window by window) of packets because the sender needs ACK’s. The adapter may fall asleep between gaps and ACK’s may be delayed by 100+ ms. This adds to the RTT and the sender will make estimates based on it, impacting congestion algorithms.

Another example is WebSocket, where a server may push messages to the client. The clients with sleeping wireless adapters may see additional delays.

Here’s a demo. Connect to an SSH server in the same WLAN from the MacBook and run the following command and capture packets with tcpdump from the SSH server side (so that we can easily get RTT’s with WireShark from the ACK’s):

for i in {1..50}; do date; sleep $interval; done

First with interval=0.1 and then again with interval=2. Below is a comparison. Clearly RTT’s are much larger when packets come from the server with large intervals.

Left: interval=0.1 (sender sends quickly)
Right: interval=2 (sender sends slowly)

One more thing

Besides all the factors mentioned above, we have the hard-working AirDrop. Sometimes it gets in the way and create latency spikes.

Here’s how latency to gateway looks like when AirDrop is on. To be clear, it’s not working to transfer files between devices. It’s just waiting, or scanning, I guess.

ping [gateway]

The line flattens at around sequence 180 when I disabled AirDrop with

sudo ifconfig awdl0 down

I did some preliminary testing with 2 TCP flows, with RTT’s of 20 ms and 130 ms respectively. Both showed 30% speed improvement when I turned off the awdl0 interface.

Sleep well

In this post, I showed how a sleeping MacBook still keeps its wireless adapter working, how an awake MacBook puts its wireless adapter to sleep at times, and the possible impacts of this behavior. I also showed what we sacrificed for the occasional convenience of AirDrop.

The explorations I did were not extensive, and it’s hard to keep a quiet wireless environment for testing. By the way I know nothing about 802.11 protocols. If I missed anything, or you’re simply interested in a discussion, put your thoughts below!

Leave a comment

Your email address will not be published. Required fields are marked *

Prove your intelligence before hitting * Time limit is exhausted. Please reload CAPTCHA.