10
9
I'm experiencing high wifi latency every other second on my Macbook Pro, running the latest macOS Sierra.
I thought my old router might be the culprit, so I bought a new one. However the new router only made things worse, going from latency issues to about 20% packet loss. Trying this solution from another Super User question at least brought the packet loss down to 0 again, but the latency issue remains.
- Pinging the same router from another machine via wired network results in a steady 2ms ping.
- Pinging from my phone over wifi results in a steady 4ms ping (old Android phone).
- Running the same tests on my network at work yields the exact same results. I've singled out my Macbook Pro's wifi as the issue.
Here's a chart from speedtest.net. I get about the same result every time I run this test on wifi: a ~5 second dip in download speed.
When pinging my router at 192.168.1.1 from my MBP (at the default 1 Hz), I get the following pattern:
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=86.944 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=121.099 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.664 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=31.493 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=66.042 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=99.786 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=2.459 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=2.183 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.867 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=2.662 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=2.065 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=0.877 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=63.238 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=101.419 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=3.704 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=36.746 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=51.972 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=86.453 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=125.786 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=1.113 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=1.973 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=2.575 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=1.957 ms
64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=2.209 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=2.815 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=1.924 ms
64 bytes from 192.168.1.1: icmp_seq=26 ttl=64 time=150.076 ms
64 bytes from 192.168.1.1: icmp_seq=27 ttl=64 time=53.943 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=64 time=84.633 ms
64 bytes from 192.168.1.1: icmp_seq=29 ttl=64 time=109.776 ms
Pinging at 10 Hz results in a similar pattern, with packet loss:
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=1.078 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=1.347 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=1.041 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=1.031 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=1.098 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=1.098 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=0.944 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=3.185 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=8.736 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=6.846 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=1.009 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=0.900 ms
64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=0.985 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=0.898 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=0.919 ms
64 bytes from 192.168.1.1: icmp_seq=26 ttl=64 time=3.679 ms
64 bytes from 192.168.1.1: icmp_seq=27 ttl=64 time=1.468 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=64 time=6.889 ms
64 bytes from 192.168.1.1: icmp_seq=29 ttl=64 time=0.953 ms
64 bytes from 192.168.1.1: icmp_seq=30 ttl=64 time=1.076 ms
64 bytes from 192.168.1.1: icmp_seq=31 ttl=64 time=0.984 ms
64 bytes from 192.168.1.1: icmp_seq=32 ttl=64 time=0.946 ms
64 bytes from 192.168.1.1: icmp_seq=33 ttl=64 time=0.872 ms
64 bytes from 192.168.1.1: icmp_seq=34 ttl=64 time=0.844 ms
Request timeout for icmp_seq 35
64 bytes from 192.168.1.1: icmp_seq=35 ttl=64 time=169.385 ms
64 bytes from 192.168.1.1: icmp_seq=36 ttl=64 time=68.897 ms
64 bytes from 192.168.1.1: icmp_seq=37 ttl=64 time=203.066 ms
64 bytes from 192.168.1.1: icmp_seq=38 ttl=64 time=98.576 ms
64 bytes from 192.168.1.1: icmp_seq=39 ttl=64 time=0.891 ms
64 bytes from 192.168.1.1: icmp_seq=40 ttl=64 time=122.991 ms
64 bytes from 192.168.1.1: icmp_seq=41 ttl=64 time=18.420 ms
64 bytes from 192.168.1.1: icmp_seq=42 ttl=64 time=90.086 ms
64 bytes from 192.168.1.1: icmp_seq=43 ttl=64 time=1.029 ms
64 bytes from 192.168.1.1: icmp_seq=44 ttl=64 time=65.268 ms
64 bytes from 192.168.1.1: icmp_seq=45 ttl=64 time=92.355 ms
64 bytes from 192.168.1.1: icmp_seq=46 ttl=64 time=0.922 ms
64 bytes from 192.168.1.1: icmp_seq=47 ttl=64 time=66.303 ms
64 bytes from 192.168.1.1: icmp_seq=49 ttl=64 time=38.938 ms
Request timeout for icmp_seq 50
64 bytes from 192.168.1.1: icmp_seq=50 ttl=64 time=129.508 ms
64 bytes from 192.168.1.1: icmp_seq=51 ttl=64 time=24.909 ms
64 bytes from 192.168.1.1: icmp_seq=52 ttl=64 time=86.077 ms
64 bytes from 192.168.1.1: icmp_seq=53 ttl=64 time=0.967 ms
64 bytes from 192.168.1.1: icmp_seq=54 ttl=64 time=198.241 ms
64 bytes from 192.168.1.1: icmp_seq=55 ttl=64 time=93.977 ms
64 bytes from 192.168.1.1: icmp_seq=56 ttl=64 time=0.886 ms
64 bytes from 192.168.1.1: icmp_seq=57 ttl=64 time=70.865 ms
64 bytes from 192.168.1.1: icmp_seq=58 ttl=64 time=0.809 ms
64 bytes from 192.168.1.1: icmp_seq=59 ttl=64 time=41.784 ms
Request timeout for icmp_seq 61
64 bytes from 192.168.1.1: icmp_seq=62 ttl=64 time=90.258 ms
64 bytes from 192.168.1.1: icmp_seq=63 ttl=64 time=1.207 ms
64 bytes from 192.168.1.1: icmp_seq=64 ttl=64 time=56.740 ms
64 bytes from 192.168.1.1: icmp_seq=65 ttl=64 time=85.553 ms
64 bytes from 192.168.1.1: icmp_seq=66 ttl=64 time=0.877 ms
64 bytes from 192.168.1.1: icmp_seq=67 ttl=64 time=62.510 ms
64 bytes from 192.168.1.1: icmp_seq=68 ttl=64 time=1.423 ms
64 bytes from 192.168.1.1: icmp_seq=69 ttl=64 time=32.156 ms
Request timeout for icmp_seq 70
64 bytes from 192.168.1.1: icmp_seq=70 ttl=64 time=116.203 ms
64 bytes from 192.168.1.1: icmp_seq=71 ttl=64 time=12.917 ms
64 bytes from 192.168.1.1: icmp_seq=72 ttl=64 time=86.092 ms
64 bytes from 192.168.1.1: icmp_seq=73 ttl=64 time=0.886 ms
64 bytes from 192.168.1.1: icmp_seq=74 ttl=64 time=59.710 ms
64 bytes from 192.168.1.1: icmp_seq=75 ttl=64 time=90.512 ms
64 bytes from 192.168.1.1: icmp_seq=76 ttl=64 time=4.074 ms
64 bytes from 192.168.1.1: icmp_seq=77 ttl=64 time=111.984 ms
64 bytes from 192.168.1.1: icmp_seq=78 ttl=64 time=8.640 ms
64 bytes from 192.168.1.1: icmp_seq=79 ttl=64 time=152.531 ms
64 bytes from 192.168.1.1: icmp_seq=80 ttl=64 time=47.904 ms
64 bytes from 192.168.1.1: icmp_seq=81 ttl=64 time=0.907 ms
64 bytes from 192.168.1.1: icmp_seq=82 ttl=64 time=75.134 ms
64 bytes from 192.168.1.1: icmp_seq=83 ttl=64 time=1.012 ms
64 bytes from 192.168.1.1: icmp_seq=84 ttl=64 time=42.029 ms
64 bytes from 192.168.1.1: icmp_seq=85 ttl=64 time=116.824 ms
64 bytes from 192.168.1.1: icmp_seq=86 ttl=64 time=14.382 ms
64 bytes from 192.168.1.1: icmp_seq=87 ttl=64 time=49.502 ms
64 bytes from 192.168.1.1: icmp_seq=88 ttl=64 time=121.049 ms
64 bytes from 192.168.1.1: icmp_seq=89 ttl=64 time=21.011 ms
64 bytes from 192.168.1.1: icmp_seq=90 ttl=64 time=95.133 ms
64 bytes from 192.168.1.1: icmp_seq=91 ttl=64 time=1.043 ms
64 bytes from 192.168.1.1: icmp_seq=92 ttl=64 time=67.754 ms
64 bytes from 192.168.1.1: icmp_seq=93 ttl=64 time=0.876 ms
64 bytes from 192.168.1.1: icmp_seq=94 ttl=64 time=39.027 ms
64 bytes from 192.168.1.1: icmp_seq=95 ttl=64 time=110.931 ms
64 bytes from 192.168.1.1: icmp_seq=96 ttl=64 time=7.023 ms
64 bytes from 192.168.1.1: icmp_seq=97 ttl=64 time=36.249 ms
64 bytes from 192.168.1.1: icmp_seq=98 ttl=64 time=116.108 ms
64 bytes from 192.168.1.1: icmp_seq=99 ttl=64 time=11.732 ms
64 bytes from 192.168.1.1: icmp_seq=100 ttl=64 time=82.880 ms
64 bytes from 192.168.1.1: icmp_seq=101 ttl=64 time=0.956 ms
64 bytes from 192.168.1.1: icmp_seq=102 ttl=64 time=58.007 ms
64 bytes from 192.168.1.1: icmp_seq=103 ttl=64 time=126.818 ms
64 bytes from 192.168.1.1: icmp_seq=104 ttl=64 time=22.750 ms
64 bytes from 192.168.1.1: icmp_seq=105 ttl=64 time=99.126 ms
64 bytes from 192.168.1.1: icmp_seq=106 ttl=64 time=131.419 ms
64 bytes from 192.168.1.1: icmp_seq=107 ttl=64 time=28.596 ms
64 bytes from 192.168.1.1: icmp_seq=108 ttl=64 time=110.326 ms
64 bytes from 192.168.1.1: icmp_seq=109 ttl=64 time=5.859 ms
64 bytes from 192.168.1.1: icmp_seq=110 ttl=64 time=70.852 ms
64 bytes from 192.168.1.1: icmp_seq=111 ttl=64 time=0.855 ms
64 bytes from 192.168.1.1: icmp_seq=112 ttl=64 time=41.162 ms
64 bytes from 192.168.1.1: icmp_seq=113 ttl=64 time=114.014 ms
64 bytes from 192.168.1.1: icmp_seq=114 ttl=64 time=9.519 ms
Request timeout for icmp_seq 116
64 bytes from 192.168.1.1: icmp_seq=116 ttl=64 time=121.307 ms
64 bytes from 192.168.1.1: icmp_seq=117 ttl=64 time=16.106 ms
64 bytes from 192.168.1.1: icmp_seq=118 ttl=64 time=1.082 ms
64 bytes from 192.168.1.1: icmp_seq=119 ttl=64 time=1.086 ms
64 bytes from 192.168.1.1: icmp_seq=120 ttl=64 time=1.386 ms
64 bytes from 192.168.1.1: icmp_seq=121 ttl=64 time=1.002 ms
64 bytes from 192.168.1.1: icmp_seq=122 ttl=64 time=5.472 ms
64 bytes from 192.168.1.1: icmp_seq=123 ttl=64 time=1.060 ms
64 bytes from 192.168.1.1: icmp_seq=124 ttl=64 time=1.526 ms
64 bytes from 192.168.1.1: icmp_seq=125 ttl=64 time=0.998 ms
64 bytes from 192.168.1.1: icmp_seq=126 ttl=64 time=1.182 ms
64 bytes from 192.168.1.1: icmp_seq=127 ttl=64 time=0.942 ms
64 bytes from 192.168.1.1: icmp_seq=128 ttl=64 time=3.221 ms
64 bytes from 192.168.1.1: icmp_seq=129 ttl=64 time=16.895 ms
64 bytes from 192.168.1.1: icmp_seq=130 ttl=64 time=1.251 ms
64 bytes from 192.168.1.1: icmp_seq=131 ttl=64 time=3.832 ms
64 bytes from 192.168.1.1: icmp_seq=132 ttl=64 time=5.403 ms
64 bytes from 192.168.1.1: icmp_seq=133 ttl=64 time=1.194 ms
64 bytes from 192.168.1.1: icmp_seq=134 ttl=64 time=1.287 ms
64 bytes from 192.168.1.1: icmp_seq=135 ttl=64 time=2.274 ms
64 bytes from 192.168.1.1: icmp_seq=136 ttl=64 time=0.863 ms
64 bytes from 192.168.1.1: icmp_seq=138 ttl=64 time=1.200 ms
In words: ~5 seconds of normal pings, then ~5 seconds of serious latency issues or even timeouts if the ping frequency is high enough.
I've tried figuring out if a recent app install may be causing this, so I've disabled most apps already (Dropbox, Little Snitch). I'm running out of options now though. I've just run Wireshark while pinging, and see no network activity at all except for these pings.
I'm unsure what else I can try to figure this one out.
Are these standard once-per-second pings? If your only traffic is once-per-second pings, it allows 802.11 Power Save to kick in (in between pings) which messes with latency. But it's just a measurement error, because real TCP or UDP flows wouldn't just be one packet every second, so Power Save wouldn't kick in. See if
sudo ping -i 0.1 192.168.1.1
(ten pings per second) has different results. That makes your client send one ping per typical beacon interval (tenth of a second), which can keep Power Save from kicking in. – Spiff – 2016-11-08T00:04:30.783Thanks Spiff, but WiFi power saving is not the issue. I'm experiencing the exact same issues streaming videos online via WiFi, both at home and at work. Once I plug in the network cable, everything is fine. My Android phone is perfectly capable to stream in HD on both WiFi networks. – Robbert – 2016-11-10T12:20:48.720
Absent any other evidence, I'd still bet Wi-Fi power save is the reason for the ping time variation you documented above. Video streaming across the Internet is a very different application than tiny local once-per-second pings, and should be troubleshot on its own. – Spiff – 2016-11-10T14:47:40.077
1@spiff I understand where you're coming from. I've updated my answer with similar results from the suggested 10 Hz ping. The only difference now is that I'm losing packets due to the increased frequency. – Robbert – 2016-11-10T19:02:36.090
What protocol are you using for your video streaming? Most modern streaming, even one-way "live" video, is buffered long enough that occasional 100-150ms stalls like you've documented shouldn't deplete the buffer. – Spiff – 2016-11-11T01:04:32.163
I was referring to YouTube. Note these stalls are not occasional, as my bandwidth and latency both drop significantly for ~5 seconds before returning to normal for a few more seconds. I just figured that it'd be more helpful to show the problem at its lowest level - pings timing out. I've updated my post with a screenshot from speedtest.net, where you can see a significant drop in bandwidth. Running the same test on a wired network yields a steady line without bandwidth drops. – Robbert – 2016-11-11T07:23:38.037
I'm curious, does the old Android phone on Wi-Fi have similar YouTube or Speedtest.net problems? I know it doesn't show the ping latency variation, but I'm curious if it has the same problems with the same YouTube and Speedtest traffic as you see on your Mac. – Spiff – 2016-11-12T01:56:23.997
No, the Android phone is showing a constant download speed. It's just the MBP. Note I get the same results on different wifi networks. – Robbert – 2016-11-13T12:53:26.943
The issue had resolved itself for me yesterday. I'm thinking it must have been an app that was causing WiFi scans or something similar as described in user666105's answer, that now no longer causes the issue with a recent update. Hope it stays away. Thanks for your help @Spiff. – Robbert – 2016-11-21T07:42:05.617
Any solutions here? Rebooting seems to work temporarily. – niry – 2017-05-11T23:37:31.617
Rebooting works. I have the same issue and I am surprised that Apple didn't fix this. It's been about a year since I noticed that in the very first time. – Ben Sinclair – 2018-05-26T15:14:38.377