Macbook Pro WiFi long ping time

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?

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:

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.

I have EXACTLY the same issue with my late 15-inch 2017 MacBook Pro w/TouchBar. I'm a networking geek and I keep an eye on these sorts of things, and I definitely wasn't having these problems a few weeks ago... I am starting to get suspicious of 10.13.3.

I have performed tests in different rooms, with three different routers from different brands, all with the same results. I have tried different channels and different frequencies (2.4 & 5Ghz) and performed tests at different times of day. It looks like at least one other user in these forums is reporting a similar problem as well.

Just like you, my iPhone X has a consistent ping to my router of around 10ms (1 ft. away from my MacBook). Here's what things look like from my MacBook, sitting across the room (about 10 ft.) from my Linksys WRT3200ACM, with no obstructions between them...

Something is up...

The spectrum is clear. Here's Wi-Fi Explorer. As you can see, my "Faster" network spread is well clear of all the others in the 5Ghz band:

That did nothing to help my latency:

PING 10.0.0.1 (10.0.0.1): 56 data bytes

64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=146.846 ms

64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=3.401 ms

64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=566.452 ms

64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=2.256 ms

64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=6.883 ms

64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=51.089 ms

64 bytes from 10.0.0.1: icmp_seq=6 ttl=64 time=2.329 ms

64 bytes from 10.0.0.1: icmp_seq=7 ttl=64 time=3.527 ms

64 bytes from 10.0.0.1: icmp_seq=8 ttl=64 time=2.995 ms

64 bytes from 10.0.0.1: icmp_seq=9 ttl=64 time=2.188 ms

64 bytes from 10.0.0.1: icmp_seq=10 ttl=64 time=138.442 ms

64 bytes from 10.0.0.1: icmp_seq=11 ttl=64 time=54.515 ms

64 bytes from 10.0.0.1: icmp_seq=12 ttl=64 time=162.044 ms

64 bytes from 10.0.0.1: icmp_seq=13 ttl=64 time=150.850 ms

64 bytes from 10.0.0.1: icmp_seq=14 ttl=64 time=198.049 ms

64 bytes from 10.0.0.1: icmp_seq=15 ttl=64 time=240.640 ms

64 bytes from 10.0.0.1: icmp_seq=16 ttl=64 time=289.025 ms

64 bytes from 10.0.0.1: icmp_seq=17 ttl=64 time=231.027 ms

64 bytes from 10.0.0.1: icmp_seq=18 ttl=64 time=21.792 ms

64 bytes from 10.0.0.1: icmp_seq=19 ttl=64 time=2.062 ms

64 bytes from 10.0.0.1: icmp_seq=20 ttl=64 time=3.117 ms

64 bytes from 10.0.0.1: icmp_seq=21 ttl=64 time=1.881 ms

64 bytes from 10.0.0.1: icmp_seq=22 ttl=64 time=2.122 ms

64 bytes from 10.0.0.1: icmp_seq=23 ttl=64 time=1.997 ms

64 bytes from 10.0.0.1: icmp_seq=24 ttl=64 time=61.443 ms

64 bytes from 10.0.0.1: icmp_seq=25 ttl=64 time=248.052 ms

64 bytes from 10.0.0.1: icmp_seq=26 ttl=64 time=343.722 ms

64 bytes from 10.0.0.1: icmp_seq=27 ttl=64 time=142.273 ms

64 bytes from 10.0.0.1: icmp_seq=28 ttl=64 time=191.563 ms

64 bytes from 10.0.0.1: icmp_seq=29 ttl=64 time=2.038 ms

64 bytes from 10.0.0.1: icmp_seq=30 ttl=64 time=3.093 ms

64 bytes from 10.0.0.1: icmp_seq=31 ttl=64 time=2.017 ms

64 bytes from 10.0.0.1: icmp_seq=32 ttl=64 time=2.246 ms

64 bytes from 10.0.0.1: icmp_seq=33 ttl=64 time=2.094 ms

64 bytes from 10.0.0.1: icmp_seq=34 ttl=64 time=2.319 ms

64 bytes from 10.0.0.1: icmp_seq=35 ttl=64 time=23.132 ms

64 bytes from 10.0.0.1: icmp_seq=36 ttl=64 time=36.311 ms

64 bytes from 10.0.0.1: icmp_seq=37 ttl=64 time=198.694 ms

64 bytes from 10.0.0.1: icmp_seq=38 ttl=64 time=175.203 ms

64 bytes from 10.0.0.1: icmp_seq=39 ttl=64 time=306.300 ms

64 bytes from 10.0.0.1: icmp_seq=40 ttl=64 time=353.589 ms

64 bytes from 10.0.0.1: icmp_seq=41 ttl=64 time=402.543 ms

64 bytes from 10.0.0.1: icmp_seq=42 ttl=64 time=449.449 ms

64 bytes from 10.0.0.1: icmp_seq=43 ttl=64 time=5.465 ms

64 bytes from 10.0.0.1: icmp_seq=44 ttl=64 time=11.894 ms

64 bytes from 10.0.0.1: icmp_seq=45 ttl=64 time=16.097 ms

64 bytes from 10.0.0.1: icmp_seq=46 ttl=64 time=2.034 ms

64 bytes from 10.0.0.1: icmp_seq=47 ttl=64 time=1.911 ms

64 bytes from 10.0.0.1: icmp_seq=48 ttl=64 time=24.571 ms

64 bytes from 10.0.0.1: icmp_seq=49 ttl=64 time=2.157 ms

64 bytes from 10.0.0.1: icmp_seq=50 ttl=64 time=213.233 ms

The ICMP packets from both devices are the same size. I'm using Net Analyzer on my iPhone X with a default payload size of 56 bytes, the same default used with MacOS's ping tool. Here's what it shows in a test taken just seconds after the one I pasted above, with the iPhone sitting 8 inches away from the MacBook at my desk:

I should note, once again, that everything was working very well until the last few weeks. This has nothing to do with the MacBook or iPhone antennas. Something is up.

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

.

if you want that and also want to look at the spectrum, WiFi Explorer is cheap and has a three day free trial in the Mac App store:

drag and drop on Preview, then stretch and scroll the window for larger.

See how, in this example, G7HS7_15 in orange, spreads up and down the spectrum, overlapping MANY other networks.

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.

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.

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.

Something is up.

your neighbors are busily moving their Routers to different channels, to get better reception. The network named Faster (80 MHz wide) is now down at 112 instead of up in the 160's.

Where is the one with the hidden-name network?

what it TWCWiFiPasspoint? it has a similar, but not identical numbers to others, which I presume are yours.

My network is called "Faster". I manually set my router to use Ch. 112 for testing; it made no difference with the intermittent latency. As I said in my original post, I've tried many different channels, but nothing helps.

I am not suggesting there is a hardware or antenna problem, I am suspicious of a software/driver problem with the recent MacOS update.

I'm not going to run etrecheck. This is a top-of-the-line, three-month-old MacBook Pro which has worked wonderfully in this location, with this router, since I got it. CPU usage stays between 0.8% and 2.5%, there's plenty of free memory, no network usage during these tests, and the problem persists between multiple restarts.