Macbook Pro WiFi long ping time

Question

Macbook Pro WiFi long ping time

Hello. I've got an issue that's come up on this discussion category before with the late 2016 MBP w/touchbar (model MBP 13,3): long WiFi pings. Another user posted a short/long oscillating ping time to his WiFi router. I'm having the same problem, and the previous thread was closed before a solution was reached.

Recap of the problem... You'll see 50 pings from my MBP to my Netgear Nighthawk R7000 router, followed by 50 from my iPhone 7.

Macbook Pro:

64 bytes from 192.168.11.1: icmp_seq=0 ttl=64 time=0.985 ms

64 bytes from 192.168.11.1: icmp_seq=1 ttl=64 time=183.609 ms

64 bytes from 192.168.11.1: icmp_seq=2 ttl=64 time=301.731 ms

64 bytes from 192.168.11.1: icmp_seq=3 ttl=64 time=764.977 ms

64 bytes from 192.168.11.1: icmp_seq=4 ttl=64 time=532.749 ms

64 bytes from 192.168.11.1: icmp_seq=5 ttl=64 time=423.662 ms

64 bytes from 192.168.11.1: icmp_seq=6 ttl=64 time=109.228 ms

64 bytes from 192.168.11.1: icmp_seq=7 ttl=64 time=647.522 ms

64 bytes from 192.168.11.1: icmp_seq=8 ttl=64 time=0.957 ms

64 bytes from 192.168.11.1: icmp_seq=9 ttl=64 time=1.473 ms

64 bytes from 192.168.11.1: icmp_seq=10 ttl=64 time=1.925 ms

64 bytes from 192.168.11.1: icmp_seq=11 ttl=64 time=2.346 ms

64 bytes from 192.168.11.1: icmp_seq=12 ttl=64 time=2.694 ms

64 bytes from 192.168.11.1: icmp_seq=13 ttl=64 time=2.498 ms

64 bytes from 192.168.11.1: icmp_seq=14 ttl=64 time=162.144 ms

64 bytes from 192.168.11.1: icmp_seq=15 ttl=64 time=291.535 ms

64 bytes from 192.168.11.1: icmp_seq=16 ttl=64 time=139.565 ms

64 bytes from 192.168.11.1: icmp_seq=17 ttl=64 time=114.130 ms

64 bytes from 192.168.11.1: icmp_seq=18 ttl=64 time=193.848 ms

64 bytes from 192.168.11.1: icmp_seq=19 ttl=64 time=356.472 ms

64 bytes from 192.168.11.1: icmp_seq=20 ttl=64 time=15.614 ms

64 bytes from 192.168.11.1: icmp_seq=21 ttl=64 time=377.467 ms

64 bytes from 192.168.11.1: icmp_seq=22 ttl=64 time=323.144 ms

64 bytes from 192.168.11.1: icmp_seq=23 ttl=64 time=11.042 ms

64 bytes from 192.168.11.1: icmp_seq=24 ttl=64 time=53.428 ms

64 bytes from 192.168.11.1: icmp_seq=25 ttl=64 time=90.603 ms

64 bytes from 192.168.11.1: icmp_seq=26 ttl=64 time=2.809 ms

64 bytes from 192.168.11.1: icmp_seq=27 ttl=64 time=2.028 ms

64 bytes from 192.168.11.1: icmp_seq=28 ttl=64 time=19.199 ms

64 bytes from 192.168.11.1: icmp_seq=29 ttl=64 time=2.303 ms

64 bytes from 192.168.11.1: icmp_seq=30 ttl=64 time=2.118 ms

64 bytes from 192.168.11.1: icmp_seq=31 ttl=64 time=142.155 ms

64 bytes from 192.168.11.1: icmp_seq=32 ttl=64 time=267.978 ms

64 bytes from 192.168.11.1: icmp_seq=33 ttl=64 time=730.390 ms

64 bytes from 192.168.11.1: icmp_seq=34 ttl=64 time=496.511 ms

64 bytes from 192.168.11.1: icmp_seq=35 ttl=64 time=377.961 ms

64 bytes from 192.168.11.1: icmp_seq=36 ttl=64 time=0.967 ms

64 bytes from 192.168.11.1: icmp_seq=37 ttl=64 time=397.723 ms

64 bytes from 192.168.11.1: icmp_seq=38 ttl=64 time=166.925 ms

64 bytes from 192.168.11.1: icmp_seq=39 ttl=64 time=1.047 ms

64 bytes from 192.168.11.1: icmp_seq=40 ttl=64 time=1.977 ms

64 bytes from 192.168.11.1: icmp_seq=41 ttl=64 time=2.157 ms

64 bytes from 192.168.11.1: icmp_seq=42 ttl=64 time=2.821 ms

64 bytes from 192.168.11.1: icmp_seq=43 ttl=64 time=1.022 ms

64 bytes from 192.168.11.1: icmp_seq=44 ttl=64 time=1.047 ms

64 bytes from 192.168.11.1: icmp_seq=45 ttl=64 time=107.489 ms

64 bytes from 192.168.11.1: icmp_seq=46 ttl=64 time=359.644 ms

64 bytes from 192.168.11.1: icmp_seq=47 ttl=64 time=128.508 ms

64 bytes from 192.168.11.1: icmp_seq=48 ttl=64 time=173.255 ms

64 bytes from 192.168.11.1: icmp_seq=49 ttl=64 time=354.999 ms

64 bytes from 192.168.11.1: icmp_seq=50 ttl=64 time=47.964 ms

You can see the back and forth. Some pings over 1/2 a second, some pings under 1 millisecond... really inconsistent performance... and you can see the fruits of that especially when I'm coping files on my LAN.

and now 50 pings from my iPhone 7, connected to the same WiFi router:

64 bytes from 192.168.11.1: icmp_seq=0 ttl=64 time=37.430 ms

64 bytes from 192.168.11.1: icmp_seq=1 ttl=64 time=11.955 ms

64 bytes from 192.168.11.1: icmp_seq=2 ttl=64 time=6.737 ms

64 bytes from 192.168.11.1: icmp_seq=3 ttl=64 time=8.101 ms

64 bytes from 192.168.11.1: icmp_seq=4 ttl=64 time=14.486 ms

64 bytes from 192.168.11.1: icmp_seq=5 ttl=64 time=13.315 ms

64 bytes from 192.168.11.1: icmp_seq=6 ttl=64 time=15.315 ms

64 bytes from 192.168.11.1: icmp_seq=7 ttl=64 time=14.153 ms

64 bytes from 192.168.11.1: icmp_seq=8 ttl=64 time=16.863 ms

64 bytes from 192.168.11.1: icmp_seq=9 ttl=64 time=16.113 ms

64 bytes from 192.168.11.1: icmp_seq=10 ttl=64 time=2.665 ms

64 bytes from 192.168.11.1: icmp_seq=11 ttl=64 time=13.714 ms

64 bytes from 192.168.11.1: icmp_seq=12 ttl=64 time=4.598 ms

64 bytes from 192.168.11.1: icmp_seq=13 ttl=64 time=7.731 ms

64 bytes from 192.168.11.1: icmp_seq=14 ttl=64 time=17.913 ms

64 bytes from 192.168.11.1: icmp_seq=15 ttl=64 time=16.114 ms

64 bytes from 192.168.11.1: icmp_seq=16 ttl=64 time=17.863 ms

64 bytes from 192.168.11.1: icmp_seq=17 ttl=64 time=16.181 ms

64 bytes from 192.168.11.1: icmp_seq=18 ttl=64 time=17.803 ms

64 bytes from 192.168.11.1: icmp_seq=19 ttl=64 time=17.603 ms

64 bytes from 192.168.11.1: icmp_seq=20 ttl=64 time=18.353 ms

64 bytes from 192.168.11.1: icmp_seq=21 ttl=64 time=4.654 ms

64 bytes from 192.168.11.1: icmp_seq=22 ttl=64 time=6.708 ms

64 bytes from 192.168.11.1: icmp_seq=23 ttl=64 time=18.336 ms

64 bytes from 192.168.11.1: icmp_seq=24 ttl=64 time=17.424 ms

64 bytes from 192.168.11.1: icmp_seq=25 ttl=64 time=7.046 ms

64 bytes from 192.168.11.1: icmp_seq=26 ttl=64 time=17.466 ms

64 bytes from 192.168.11.1: icmp_seq=27 ttl=64 time=7.403 ms

64 bytes from 192.168.11.1: icmp_seq=28 ttl=64 time=17.738 ms

64 bytes from 192.168.11.1: icmp_seq=29 ttl=64 time=6.952 ms

64 bytes from 192.168.11.1: icmp_seq=30 ttl=64 time=18.160 ms

64 bytes from 192.168.11.1: icmp_seq=31 ttl=64 time=19.429 ms

64 bytes from 192.168.11.1: icmp_seq=32 ttl=64 time=7.184 ms

64 bytes from 192.168.11.1: icmp_seq=33 ttl=64 time=4.413 ms

64 bytes from 192.168.11.1: icmp_seq=34 ttl=64 time=18.027 ms

64 bytes from 192.168.11.1: icmp_seq=35 ttl=64 time=19.121 ms

64 bytes from 192.168.11.1: icmp_seq=36 ttl=64 time=18.408 ms

64 bytes from 192.168.11.1: icmp_seq=37 ttl=64 time=19.173 ms

64 bytes from 192.168.11.1: icmp_seq=38 ttl=64 time=18.664 ms

64 bytes from 192.168.11.1: icmp_seq=39 ttl=64 time=19.574 ms

64 bytes from 192.168.11.1: icmp_seq=40 ttl=64 time=7.911 ms

64 bytes from 192.168.11.1: icmp_seq=41 ttl=64 time=7.958 ms

64 bytes from 192.168.11.1: icmp_seq=42 ttl=64 time=5.647 ms

64 bytes from 192.168.11.1: icmp_seq=43 ttl=64 time=8.011 ms

64 bytes from 192.168.11.1: icmp_seq=44 ttl=64 time=7.967 ms

64 bytes from 192.168.11.1: icmp_seq=45 ttl=64 time=7.963 ms

64 bytes from 192.168.11.1: icmp_seq=46 ttl=64 time=7.913 ms

64 bytes from 192.168.11.1: icmp_seq=47 ttl=64 time=7.980 ms

64 bytes from 192.168.11.1: icmp_seq=48 ttl=64 time=7.992 ms

64 bytes from 192.168.11.1: icmp_seq=49 ttl=64 time=7.961 ms

64 bytes from 192.168.11.1: icmp_seq=50 ttl=64 time=7.959 ms

As you can see, the performance of the MBP beats iPhone 7 at shortest ping time, but iPhone 7 *destroys* my MBP in terms of consistency. The previous post suggested that the user take his MBP to the Apple Store and ask that they physically open the machine to check if the antennas were broken, or their wires damaged or some other hardware issue.

I've also tested using a hardwire connection. Obviously, this solution offers the best performance, with pings almost always under 1 millisecond. So it's seems the problem is the WiFi on the MBP.

I'm thumping this problem again to see if anyone else has experienced it and solved it.

Thanks, y'all!

MacBook Pro TouchBar and Touch ID, macOS Sierra (10.12.6)

Posted on Feb 22, 2018 12:00 PM

Reply

Answer 1

Top-ranking reply

Ian Whitworth Author

Level 1

29 points

Feb 28, 2018 9:25 AM in response to Ian Whitworth

Thanks, everyone, for their help here. I think I figured it out. Turns out to be a software issue.

The culprit was Avid Application Manager. This is a software update utility that Avid installs with any of its professional A/V packages: Media Composer, Pro Tools, etc. Turns out, it's a little network piggie.

The thing is a little purple icon in your menu bar. Run a ping to your router, then click on that purple icon and select "Quit". Watch your ping times plummet & your internet connection increase in speed by at least 50%.

Thanks, Avid. As usual, you (sort of) deliver on the high-level stuff, but serve up a steaming piece of garbage to run the simplest background task. It will one day be your undoing.

Reply

Answer 2

Feb 28, 2018 5:41 PM in response to DeltaHF

A 2nd tier Apple tech helped me diagnose this. I had tried making a different user profile, but AAM was installed to run at the system level - would have affect all users. It wasn't until I booted into "safe mode" that we discovered the WiFi actually worked fine. That led us to login items and kernel extensions, and we eventually exposed AAM as the culprit.

Seems the issue is known to Avid users. I heard back from one Facebook friend running AAM that he doesn't have a problem, but his Avid workstation uses a wired connection primarily. So it really seems to be a WiFi problem exclusively (which is indeed puzzling). I never thought such a simple piece of software could be such a WiFi piggie in the background.

Hope this thread helps someone else, and good luck with the Transmit developers.

Cheers, y'all!

Reply

Answer 3

Feb 22, 2018 6:49 PM in response to Ian Whitworth

You have a very strong signal at -43, with noise much lower at -93, giving you a signal to noise of -50, truly excellent. 80 MHz channel centered around channel 44 should give you good results, and it seems to. You have a baseband speed there of about 390 Mbits/sec, and are using 3 antennas and 256-pattern QAM to get 1053 Mbits/sec over it. Your Hardware appears to be just fine.

However, you have a VERY busy neighborhood, and it may be that one of your neighbors is using something that overlaps onto you channel.

Wireless diagnostics (available from that same Menu) opens up a whole other world. There are five displays available, including one that looks like most "driver" programs:

Check for Wi-Fi issues using your Mac - Apple Support

However, DON'T create a "diagnostics report" unless someone at Apple has asked for it. It is merely a DUMP of every possible setting that could possibly influence your connection. It is so big, it is embarrassing, so they compress it. It is useless.

In the next-to-last paragraph, they list the important functions available on the menus inside Wireless Diagnostics:

• Info

• Logs

• Scan -- finds Wi-Fi routers in your environment and gathers key details about them.

• Performance

• Sniffer

• Monitor

these are really interesting, and I think you may find them helpful.

SCAN:

User uploaded file

drag and drop the graphic on Preview, and street and scroll its window to explore further.

Since you are so close to your Router, you could probably move to a much higher channel with impunity. If others try that, they will lose distance and theirs will stop working.

Reply

Answer 4

Feb 28, 2018 8:05 AM in response to DeltaHF

Be careful not to run any Wi-Fi scanner apps (e.g. WiFi Explorer) while running your ping tests. Doing so will result in high latency for short periods of time, as shown in your post.

Do you have any other apps (e.g. menu bar apps) monitoring your network connection in the background?

Reply

Answer 5

DeltaHF

Level 1

14 points

Feb 28, 2018 2:04 PM in response to Ian Whitworth

Great detective work, Ian! Thank you to everyone for your help here.

Although I have never used Avid software, through a process of elimination I determined that Transmit (the file transfer app) was the main culprit for me. Even though it wasn't doing anything — not connected to any servers, no obvious network activity, etc. — it was somehow affecting the latency of my connection.

The connection is much, much more stable now. Although I do still see the occasional spike of 100-200ms every minute or so, that's probably to be expected in a building with such a congested wireless spectrum. There may also be other apps at fault which I haven't discovered yet.

I'm going to report the issue to Transmit's developers, but of course this leads to another question: why does the problem only manifest itself via wireless? Unless both Avid and Panic (Transmit's developers) have code which reaches deep into the OS network stack below the Transport layer, their behavior should be interface-agnostic. Unless, of course, there is some kind of bug in the MacOS networking API.

Ian, you should report the issue to Avid. I will comment in this thread if I hear back from Transmit's developers. If anyone else has the Transmit software and could verify this bug, that would be great as well.

Reply

Answer 6

Feb 23, 2018 11:33 AM in response to Ian Whitworth

Ping time is a symptom of problems, but has no diagnostic information in it.

You have excellent signal strength, using all three antennas, and any problems are likely due to Direct competition from your neighbors' networks too close to yours.

Because you will be away from your neighbors' competing networks, there is nothing the Apple Store can tell you except "seems to be working fine", which I already told you.

There are several things you can do to improve stability:

1) set your Router to "automatic" channel selection. Then when it powers up, it sniffs the channels for the "least busy" channel, and begins there.

2) use the tools I suggested, or similar ones, to see whose Router is conflicting with your spectrum (factoring in not just center-channel but SPREAD, and Move to a different channel to avoid them all. YOU have the latitude, being very close to your Router, of moving to a higher channel, which does not cover quite as much distance.

3) use an Ethernet cable.

Reply

Answer 7

Feb 22, 2018 12:09 PM in response to Ian Whitworth

Long ping time is a symptom, but it offers no diagnostic information..

Hold down the option key while you click on the Wi-Fi Icon in the menubar. this presents a snapshot of performance at the moment, like this older one:

post a screenshot, or answer:

what PHY Mode and channel?

what RSSI ? and at what distance from the Router?

What Transmit rate and MCS Index?

How many networks are named?

Reply

Answer 8

Feb 24, 2018 3:13 PM in response to DeltaHF

Those are good points. It sounds like you have "done your homework" on this issue. You need not run etrecheck if you don't feel it is necessary.

What Apple will likely want to see (to NOT dismiss this as "you did this to yourself" kind of problem) is that it occurs in standard MacOS, with nothing added. They are likely to insist on an Erase and Install so that you can demonstrate your MacOS is truly clean of third-party add-ons and has not been clobbered by anything you were running previously.

So be prepared, and make sure you have a Trusted Backup, so that erasing your drive and re-Installing will not cause you any issues.

If you have access to any of: Developer Tech support, National Tech support (for huge customers), or Educational Tech support; you can make rapid progress in submitting your Bug reports directly through those organizations. Otherwise, a Genius bar appointment, or an online chat, or a phone support -- but ask for a specialist, the first responders are not likely likely to be able to deal with a problem of this complexity.

Then be prepared to dig in your heels and not be taken lightly, but INSIST that your problem is NOT solved, and on having them escalate this problem up the chain toward Engineering. You will get resistance from them, because it makes more work for the person you are dealing with.

Reply

Answer 9

Feb 28, 2018 8:15 AM in response to Ian Whitworth

Do you have any apps (i.e. menu bar apps) monitoring your network connection in the background?

Reply

Answer 10

Feb 28, 2018 10:24 AM in response to DeltaHF

DeltaHF-

are you also running this?

Launch Agents:

[...]

[Running] com.avid.ApplicationManager.plist (Avid Technology Inc - installed 2017-09-25)

.

Reply

Answer 11

Tesserax

Level 10

159,272 points

Feb 23, 2018 1:24 PM in response to Ian Whitworth

If only your MBP is having the issue AND this issue exists when you connect your MBP to other Wi-Fis (coffee shop, airport, mall, etc.) then I would agree with you that this could be a localized issue with either the MBP's built-in wireless card or its wireless antenna.

Reply

Answer 12

Feb 23, 2018 7:07 PM in response to DeltaHF

That all looks pretty, but what those tools don't show you is the spectrum SPREAD. Your signal is not JUST on one tiny nominal channel, it spreads up and down the spectrum, merging into, and ready to be clobbered by, dozens of channels.

You have TEN Routers at the top end of the spectrum, ready to interfere with your signal by ending your high speed when they send anything bigger than a simple Poll.

Wi-Fi Explorer at the App store, about US$15, and a three day free trial. Look at your network with that and you will see all ten of those Routers right on top of you and each other.

Your iPhone has a really great set of antennas, and the packets it sends are usually pretty compact compared to the bigger stuff on the bigger screen.

Reply

Answer 13

Feb 26, 2018 1:30 PM in response to DeltaHF

The only 2 access points I've tried so far have been my main Netgear Nighthawk router and hotspot to my iPhone. I've been comparing my Macbook Pro 13,3 (late 2016, touchbar) and my wife's Macbook Pro 8,1 (mid 2011). The 13,3 has ping problems with very inconsistent response times. The 8,1 doesn't have this issue and is very consistent with the response times. The router doesn't seem to matter.

Also, my iPhone 7 and my wife's 6s both have consistent ping response to our router, as does our older Android tablet and my daughter's Chromebook.

Next step for me is to take this newer MBP 13,3 to the Apple Store & prove it to them on their own network somehow.

Reply

Answer 14

Feb 23, 2018 11:21 AM in response to Grant Bennet-Alder

These are interesting tools, and you can probably tell I'm nerd enough to check them out.

However, none of those tools will explain why my iPhone has such superior consistency on the ping. You can feel the difference when browsing too. I stare a lot at "Waiting for www.[whatever].com..." or sometimes just "Connecting..." for sometimes as much as 10 seconds, while the iPhone seems to find sites easily.

I did think to connect MBP to the iPhone's hotspot and ping it that way. Here's 50 pingies from there:

64 bytes from 172.20.10.1: icmp_seq=0 ttl=64 time=394.201 ms

64 bytes from 172.20.10.1: icmp_seq=1 ttl=64 time=637.954 ms

64 bytes from 172.20.10.1: icmp_seq=2 ttl=64 time=397.818 ms

64 bytes from 172.20.10.1: icmp_seq=3 ttl=64 time=440.150 ms

Request timeout for icmp_seq 4

64 bytes from 172.20.10.1: icmp_seq=5 ttl=64 time=100.227 ms

64 bytes from 172.20.10.1: icmp_seq=6 ttl=64 time=581.092 ms

64 bytes from 172.20.10.1: icmp_seq=7 ttl=64 time=344.923 ms

64 bytes from 172.20.10.1: icmp_seq=8 ttl=64 time=2.971 ms

64 bytes from 172.20.10.1: icmp_seq=9 ttl=64 time=5.466 ms

64 bytes from 172.20.10.1: icmp_seq=10 ttl=64 time=21.526 ms

64 bytes from 172.20.10.1: icmp_seq=11 ttl=64 time=369.607 ms

64 bytes from 172.20.10.1: icmp_seq=12 ttl=64 time=60.475 ms

64 bytes from 172.20.10.1: icmp_seq=13 ttl=64 time=579.923 ms

64 bytes from 172.20.10.1: icmp_seq=14 ttl=64 time=415.657 ms

64 bytes from 172.20.10.1: icmp_seq=15 ttl=64 time=514.196 ms

64 bytes from 172.20.10.1: icmp_seq=16 ttl=64 time=210.602 ms

64 bytes from 172.20.10.1: icmp_seq=17 ttl=64 time=734.289 ms

64 bytes from 172.20.10.1: icmp_seq=18 ttl=64 time=2.975 ms

64 bytes from 172.20.10.1: icmp_seq=19 ttl=64 time=4.283 ms

64 bytes from 172.20.10.1: icmp_seq=20 ttl=64 time=2.966 ms

64 bytes from 172.20.10.1: icmp_seq=21 ttl=64 time=4.449 ms

64 bytes from 172.20.10.1: icmp_seq=22 ttl=64 time=3.317 ms

64 bytes from 172.20.10.1: icmp_seq=23 ttl=64 time=3.989 ms

64 bytes from 172.20.10.1: icmp_seq=24 ttl=64 time=3.282 ms

64 bytes from 172.20.10.1: icmp_seq=25 ttl=64 time=377.021 ms

64 bytes from 172.20.10.1: icmp_seq=26 ttl=64 time=67.644 ms

64 bytes from 172.20.10.1: icmp_seq=27 ttl=64 time=589.797 ms

64 bytes from 172.20.10.1: icmp_seq=28 ttl=64 time=432.304 ms

64 bytes from 172.20.10.1: icmp_seq=29 ttl=64 time=538.263 ms

64 bytes from 172.20.10.1: icmp_seq=30 ttl=64 time=231.098 ms

64 bytes from 172.20.10.1: icmp_seq=31 ttl=64 time=2.722 ms

64 bytes from 172.20.10.1: icmp_seq=32 ttl=64 time=308.365 ms

64 bytes from 172.20.10.1: icmp_seq=33 ttl=64 time=120.640 ms

64 bytes from 172.20.10.1: icmp_seq=34 ttl=64 time=373.052 ms

64 bytes from 172.20.10.1: icmp_seq=35 ttl=64 time=134.353 ms

64 bytes from 172.20.10.1: icmp_seq=36 ttl=64 time=150.948 ms

64 bytes from 172.20.10.1: icmp_seq=37 ttl=64 time=3.316 ms

64 bytes from 172.20.10.1: icmp_seq=38 ttl=64 time=4.652 ms

Request timeout for icmp_seq 39

64 bytes from 172.20.10.1: icmp_seq=39 ttl=64 time=1251.303 ms

64 bytes from 172.20.10.1: icmp_seq=40 ttl=64 time=246.823 ms

64 bytes from 172.20.10.1: icmp_seq=42 ttl=64 time=575.150 ms

Request timeout for icmp_seq 43

64 bytes from 172.20.10.1: icmp_seq=44 ttl=64 time=414.284 ms

64 bytes from 172.20.10.1: icmp_seq=45 ttl=64 time=174.198 ms

Request timeout for icmp_seq 46

64 bytes from 172.20.10.1: icmp_seq=47 ttl=64 time=443.803 ms

64 bytes from 172.20.10.1: icmp_seq=48 ttl=64 time=232.187 ms

64 bytes from 172.20.10.1: icmp_seq=49 ttl=64 time=4.357 ms

64 bytes from 172.20.10.1: icmp_seq=50 ttl=64 time=5.289 ms

At least at one point, you can see the same oscillation between long & short pings. Some of those ping times are terrible, I think because the iPhone & MBP are hotspotting on 2.4 GHz.

Anyway. I'm just shy of taking the MBP in to the Apple Store. Maybe on their store network, I can prove the machine's malfunction...

Reply

Answer 15

Feb 24, 2018 12:55 PM in response to DeltaHF

The graphs on your Wi-Fi performance look fine. I would say you have no evidence of busted antennas or similar Hardware problems.

But your Mac is running hundreds of tasks, and if it were to get distracted and "stuck" doing something, it is possible that so much time could elapse that it did not service the Wi-Fi in a timely fashion.

If you could run this little "discovery" utility, its report could be used to disprove the "Mac gets distracted" theory:

User Tip: Using etrecheck

.

Reply

[...]
[Running]	com.avid.ApplicationManager.plist (Avid Technology Inc - installed 2017-09-25)

Macbook Pro WiFi long ping time

Similar questions