I'm seeing intermittent latency spikes when on wifi, but only when pinging my MBP from another machine and not when pinging from the MBP to another machine. It seems to be causing stuttering with Steam In-Home Streaming. Any suggestions are greatly appreciated!
I feel strongly that this is the Mac and not the networking hardware. I've seen it on multiple access points across different vendors and channels. 2.4G and 5G are both affected.
With wifi logging enabled, nothing is logged in /var/log/wifi.log during the ping test. Location services are disabled, and I'm not clicking on the wifi icon during the test. I have tried resetting the SMC.
Update: Shown below is the minimal example. I have run this test many times and for long durations. I have been constantly ingesting ping data into InfluxDB using Telegraf. Here is the last 7 days, where the orange is my MacBook. There are a couple other anomalies present, but it's clear the high latency has been occurring for a while.
Update 2: Wireshark on the MBP shows ICMP "Response Time" as consistently < 0.1ms during the test. I believe it's looking at the time between when it sees the request come in from the reply go out.
Here's the test. 192.168.1.242 is my MBP. After quitting (nearly) every application:
craig@pluto ~> ping 192.168.1.242 -i 2
...
22 packets transmitted, 22 received, 0% packet loss, time 78ms
rtt min/avg/max/mdev = 1.037/*22.550*/*89.237*/28.546 ms
But outgoing pings are fine:
craig@Craigs-MBP ~> ping 192.168.1.3 -i 2
...
266 packets transmitted, 266 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.909/1.526/8.716/0.686 ms
Now here's something curious. If I rapidly send pings out, the inbound variance disappears!
craig@Craigs-MBP ~> ping 192.168.1.3 -i 0.2
...
417 packets transmitted, 417 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.984/1.469/3.799/0.290 ms
(while the above is running)
craig@pluto ~> ping 192.168.1.242 -i 2
...
38 packets transmitted, 38 received, 0% packet loss, time 147ms
rtt min/avg/max/mdev = 1.001/*1.664*/3.758/0.767 ms
Given this, my best guess is there is some kind of power saving mechanism turning off the radio.
craig@Craigs-MBP ~> pmset -g
System-wide power settings:
Currently in use:
standbydelaylow 10800
standby 1
womp 0
halfdim 1
hibernatefile /var/vm/sleepimage
powernap 1
gpuswitch 2
networkoversleep 0
disksleep 10
standbydelayhigh 86400
sleep 0
autopoweroffdelay 28800
hibernatemode 3
autopoweroff 1
ttyskeepawake 1
displaysleep 10
highstandbythreshold 50
acwake 0
lidwake 1
Update 3: Here are two simultaneous packet captures with the "same" ICMP packet highlighted. The left was captured using tcpdump on the Ubiquiti UniFi access point that my MBP is connected to, and the right was captured on the MBP. You can see the sequence number is the same. But the calculated response time from the access point's point-of-view is relatively high at 71 ms, while the MBP saw < 1 ms between the request and the response.
Best Answer
Yes, there is indeed such a power saving measure implemented on the Mac. This is common across WiFi chipsets on all platforms and operating systems, and is actually part of the WiFi standard itself.
The PSM (power saving mode) of the WiFi chipset takes many forms. This you're probably experiencing is known as the "connected-idle" mode. In this mode it introduces a small latency of less than 100 ms (typically 50-100 ms) for the first packet received after the module was put in the connected-idle mode.
Other power saving modes exist that save more power, but for example the connected-sleep mode introduces an extra latency of typically 300 ms, which is more than you measure here.
Unfortunately there seem to be no official interface from Apple to change power saving modes manually, or to disable certain power saving modes. The only work around is simply to actually use the radio for something which will prevent it from going into the connected-sleep mode at all. That could be done with for example a ping running in the background permanently. Obviously this will consume more power, which could be a nuisance when running on battery.
However despite the above, you should be aware that this power saving mode isn't really something that the end-user is supposed to or normally notices at all. Remember that the latency only affects the very first packet received after the module is put into connected-sleep mode, and that it is only put in connected-sleep mode after a period of nonuse.
When using Steam In-Home Streaming you would have a constant stream of packets to/from your Mac. This means that the WiFi module isn't going to go into the connected-sleep mode while streaming.