4

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

enter image description here

enter image description here

enter image description here

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.

enter image description here

|improve this question
  • Honestly, I believe your sampling is way, way to small to come to any conclusion that there's an issue. Additionally, it's important to note that WiFi latency can be caused by any number of things including traffic congestion, signal interference/strength, quality of the WAP radio, etc. For better results, you should be looking at RSSI values on different networks - this way you can at least determine if the problem exists on your network alone or all networks which will begin to narrow down the scope of the issue. – Allan Apr 18 '19 at 2:26
  • I agree - how would you discern WiFi buffering or periodic interference with such a small sample size? – bmike♦ Apr 18 '19 at 2:56
  • Allan I appreciate your honesty. I've been monitoring the latency constantly using parts of the TICK stack. Here is the last 7 days where the orange is my MBP: imgur.com/a/SsQ29UD – Craig Younkins Apr 18 '19 at 2:57
  • Also, I have seen this with multiple access points with multiple vendors, during periods when there is definitely not network congestion, across 2.4 and 5G, with the devices a few feet apart. The APs are on optimized (and separate) channels with minimal interference. Wireless diagnostics -> performance indicates things are pretty good (imgur.com/a/uRHb5PR) – Craig Younkins Apr 18 '19 at 3:07
2

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.

|improve this answer
  • 1
    You would think this wouldn't be an issue during In-Home Streaming because there is a constant video stream, but the timeout seems to be VERY aggressive - about 200 milliseconds. I see consistent spikes with ping -i 0.21 but not ping -i 0.20! I wish someone could reproduce this. – Craig Younkins Apr 21 '19 at 23:30
  • I think it is easy to reproduce actually. Are you sure there’s gaps of more than 200 ms in Steam streaming? With 4K streaming I would have assumed you would have packets much more often. You can confirm by doing a packet capture with Wireshark during streaming, and then set it to calculate the inter-packet offset. – jksoegaard Apr 22 '19 at 7:11
1

I don't think your conclusion is correct. I'd continue to diagnose the problem without making any assumptions as to what the potential reason is for your intermittent WiFi connectivity issue. It could be a whole host of reasons so the trick with this type of troubleshooting exercise is to eliminate potential sources of problems until you can build up a case as to what's causing your issue.

For starters ping isn't really a good tool for diagnosing problems like this. It can be useful for gross connectivity issues, but in this case I'd use something like PingPlotter (free for basic use) or the CLI tool mtr (available via brew.

ss1

The above shows red bars where my Macbook Pro was having intermittent issues connecting to the WiFi access point. These issues were isolated enough that we could identify that they were actually being caused by the access point and not the WiFi network in the Macbook Pro.

Once you've started to monitor things see if your issue shows any patterns.

Speed tests

You can also typically uncover intermittent issues by using something like speedtest-cli.

$ speedtest
Retrieving speedtest.net configuration...
Testing from Spectrum (65.190.136.112)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Spectrum (Durham, NC) [30.67 km]: 16.144 ms
Testing download speed................................................................................
Download: 402.10 Mbit/s
Testing upload speed................................................................................................
Upload: 21.87 Mbit/s

There's another application which is a GUI with the same name, Speedtest, from the Appstore which could be helpful if you'd rather have a GUI form of something like speedtest-cli.

Another GUI tool for analyzing your WiFi network that I've found useful is NetSpot. There's commercial as well as free options available to use it.

Discover view

ss2

Built in WiFi tools

macOS also includes a basic scanning app. It's completely not obvious how to get to it IMO. To access it you'll want to hold down the Option key, ⌥ and then click on the networking icon in the top menubar.

WiFi menu

                                           ss3

Once the diagnostic window is open you can launch additional tools from it. This is the part that most people seem to be unaware of with this app.

With the diagnostic window open and focused, look in the menubar and open up the "Windows" pulldown, within it are several tools to analyze your network.

Wireless Diagnostic dialog

ss3

Wireless Diagnostic top menubar

ss4

From this menu you can launch a variety of tools such as "Logs" to collect detailed logs or "Performance to analyze your WiFi connection.

Performance dialog

ss5

Deeper dive with Wireshark

If you're still not finding the cause of your WiFi troubles, you may want enlist the help of Wireshark. Installing it is pretty straightforward, you can use brew to install the DMG through casks (CLI + GUI) or you can install the CLI only version through the vanilla brew formula.

DMG install via cask 
$ brew cask install wireshark
CLI only 
$ brew install wireshark

When you launch the GUI, you'll need to tell it which network interface to capture data from. Here I'm telling it to capture data from my WiFi interface, en0.

ss6

If you double click the interface's name Wireshark will immediately start a packet capture session. After you've let that run for a bit, hopefully during one of failure scenarios that you're trying to troubleshoot you can click the red square to stop the capture (red #1 in diagram below).

You can then analyze the packets caught in the red #2 area of the UI and you should be able to identify types of packets (red #3, for eg. is a ping packet).

ss7

References

|improve this answer
  • 2
    Thank you! I wasn't aware of some of the things you show. Unfortunately I haven't found anything new yet. I'll need to dig into the background logs I gathered through the wireless diagnostics tool. I will also try sniffing with a third device and checking what dtrace can provide. Thanks! – Craig Younkins Apr 18 '19 at 2:47
  • Excellent comprehensive post! Would you be amenable to an edit to add Wireshark from brew? Might as well get the true measure of the ICMP pings or measure something specific :-) – bmike♦ Apr 18 '19 at 2:57
  • @bmike - sure I'll add it. My general approach is to interactively work w/ OPs and if/when they exhaust the options I've provided I'll continue to work w/ them and expand my A'ers. It's been my experience that overwhelming them with everything upfront befuddles them 8-). – slm Apr 18 '19 at 11:11
  • @bmike - i added some details around wireshark, lmk if you think anything else would be helpful here. – slm Apr 18 '19 at 11:24
  • 1
    yes - after making the comment, I was thinking the same - I should just put a small answer up on Wireshark and let you condense / skip it as the length here is more than some would like for a troubleshooting walk through. I love it, though. – bmike♦ Apr 18 '19 at 11:27

You must log in to answer this question.

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