-
All replies
-
Helpful answers
-
Nov 19, 2013 6:13 AM in response to ShaneD90by ajaffarali,Have an issue with mine as well- 13" rMBP with 8GB/256GB. I've switched my Apple Airport Express from 802.11n to 802.11b/g and that has done away with Wi-Fi issues at home but obviously not the best solution as I can't go about changing router configs everywhere
Please fix this Apple.
-
Nov 19, 2013 6:18 AM in response to ajaffaraliby vZwo,My replacement device for the rMBP 15" arrived to day. I haven't yet unpacked it and after reading your comments I somehow doubt that the problem will be fixed.
-
Nov 19, 2013 7:50 AM in response to ShaneD90by SMT990,Sounds like the same problem with the 2013 Macbook air. Several reported what was likely a wifi card/antenna problem (dropping wifi constantly) and then Apple modified the wifi driver which starting causing ping latency. My 2013 MBA was working fine until Apple borked up the wifi driver, I rolled back to the original driver and the pings went back to normal
So in summary, if your Mac is dropping the wifi connection (and you have other devices that work fine) it's very likely a hardware problem. The ping latency is a wifi driver problem. Not sure if the Macbook Pro can use the original driver from the MBA or not. I would only experiment with it on a bootable thumb drive.
https://discussions.apple.com/thread/5100655?start=1470&tstart=0
-
Nov 19, 2013 8:10 AM in response to vZwoby Pudge52,I got my second 13rMBP 8/2.6/256 Friday and I have had no problems with wifi from my Netgear N router.
Its pulling the full 300 mps with out any drops. I would say you people are having hardware problems and you should probably replace your device.
-
Nov 19, 2013 9:33 AM in response to Pudge52by mshybut,I'm having the same problem with a similar machine, new 13" rMBP 2.4/256GB/8GB RAM. It will only connect to my router via 802.11g whereas my 2011 11" MBA right next to it connects at 802.11n. The transmit rates on my MBA are sometimes as high as 10x those of the rMBP.
It's most noticeable while using AirPlay where the rMBP will constantly stutter both during audio only and video, as well as extending or mirroring the display.
I'm anticipating a hardware swap and have already contacted chat and phone support. I have an Apple Store appointment set up for Saturday.
Disappointing to have a new machine be faulty, especially when my old MBA is outperforming it.
-
Nov 19, 2013 11:49 PM in response to mshybutby wifiguru,mshybut,
what wireless router are you on ? Is it a 11ac router ? What RSSI are you at ? Use the built in Wireless Diagnostics tool to lookup your RSSI and Signal Quality.
-
Nov 20, 2013 12:04 AM in response to wifiguruby mshybut,I'm on a Linksys WRT310N, not an AC router. My RSSI is -56 on my rMBP with a transmit rate of 54 on 802.11g. My MBA is at RSSI -49, transmit rate 104 on 802.11n.
-
Nov 20, 2013 1:15 AM in response to ShaneD90by ekinfromankara,I found something interesting. My 15" late 2013 MBPR also suffers from network issues, namely latency problems on pings.
Ping to my router:
PING 10.238.238.229 (10.238.238.229): 56 data bytes
64 bytes from 10.238.238.229: icmp_seq=0 ttl=64 time=24.826 ms
64 bytes from 10.238.238.229: icmp_seq=1 ttl=64 time=46.707 ms
64 bytes from 10.238.238.229: icmp_seq=2 ttl=64 time=2.371 ms
64 bytes from 10.238.238.229: icmp_seq=3 ttl=64 time=1.521 ms
64 bytes from 10.238.238.229: icmp_seq=4 ttl=64 time=12.927 ms
64 bytes from 10.238.238.229: icmp_seq=5 ttl=64 time=36.186 ms
64 bytes from 10.238.238.229: icmp_seq=6 ttl=64 time=59.893 ms
64 bytes from 10.238.238.229: icmp_seq=7 ttl=64 time=1.510 ms
64 bytes from 10.238.238.229: icmp_seq=8 ttl=64 time=1.587 ms
64 bytes from 10.238.238.229: icmp_seq=9 ttl=64 time=0.876 ms
64 bytes from 10.238.238.229: icmp_seq=10 ttl=64 time=47.706 ms
64 bytes from 10.238.238.229: icmp_seq=11 ttl=64 time=1.751 ms
64 bytes from 10.238.238.229: icmp_seq=12 ttl=64 time=94.634 ms
However, if I start a download, it starts working perfect:
# I start downloading ubuntu disk image here
[~/Desktop]$ axel http://archive.ubuntu.com/ubuntu/.../mini.iso >/dev/null &
# Then ping, everything seems ok
[~/Desktop]$ ping 10.238.238.229
PING 10.238.238.229 (10.238.238.229): 56 data bytes
64 bytes from 10.238.238.229: icmp_seq=0 ttl=64 time=1.159 ms
64 bytes from 10.238.238.229: icmp_seq=1 ttl=64 time=1.464 ms
64 bytes from 10.238.238.229: icmp_seq=2 ttl=64 time=1.182 ms
64 bytes from 10.238.238.229: icmp_seq=3 ttl=64 time=0.984 ms
64 bytes from 10.238.238.229: icmp_seq=4 ttl=64 time=1.133 ms
64 bytes from 10.238.238.229: icmp_seq=5 ttl=64 time=1.129 ms
64 bytes from 10.238.238.229: icmp_seq=6 ttl=64 time=1.776 ms
64 bytes from 10.238.238.229: icmp_seq=7 ttl=64 time=1.457 ms
64 bytes from 10.238.238.229: icmp_seq=8 ttl=64 time=1.844 ms
64 bytes from 10.238.238.229: icmp_seq=9 ttl=64 time=1.725 ms
64 bytes from 10.238.238.229: icmp_seq=10 ttl=64 time=1.180 ms
64 bytes from 10.238.238.229: icmp_seq=11 ttl=64 time=2.507 ms
64 bytes from 10.238.238.229: icmp_seq=12 ttl=64 time=1.306 ms
64 bytes from 10.238.238.229: icmp_seq=13 ttl=64 time=1.497 ms
64 bytes from 10.238.238.229: icmp_seq=14 ttl=64 time=0.920 ms
64 bytes from 10.238.238.229: icmp_seq=15 ttl=64 time=0.872 ms
64 bytes from 10.238.238.229: icmp_seq=16 ttl=64 time=1.097 ms
64 bytes from 10.238.238.229: icmp_seq=17 ttl=64 time=1.213 ms
64 bytes from 10.238.238.229: icmp_seq=18 ttl=64 time=1.270 ms
64 bytes from 10.238.238.229: icmp_seq=19 ttl=64 time=1.361 ms
64 bytes from 10.238.238.229: icmp_seq=20 ttl=64 time=1.538 ms
64 bytes from 10.238.238.229: icmp_seq=21 ttl=64 time=1.611 ms
# Download finished at the background
[1] + 743 done axel > /dev/null
# Latencies go haywire again
64 bytes from 10.238.238.229: icmp_seq=22 ttl=64 time=1.090 ms
64 bytes from 10.238.238.229: icmp_seq=23 ttl=64 time=1.824 ms
64 bytes from 10.238.238.229: icmp_seq=24 ttl=64 time=44.799 ms
64 bytes from 10.238.238.229: icmp_seq=25 ttl=64 time=44.931 ms
64 bytes from 10.238.238.229: icmp_seq=26 ttl=64 time=44.664 ms
I think it might be abour power consumption. The device goes into low performance state when you are not taxing it. Ping itself is not taxing enough. I thought maybe there is a delay or something that kicks in. If I make ping run faster it seems to be ok too.
$ ping -i 0.1 10.238.238.229
PING 10.238.238.229 (10.238.238.229): 56 data bytes
64 bytes from 10.238.238.229: icmp_seq=0 ttl=64 time=1.320 ms
64 bytes from 10.238.238.229: icmp_seq=1 ttl=64 time=1.317 ms
64 bytes from 10.238.238.229: icmp_seq=2 ttl=64 time=0.883 ms
64 bytes from 10.238.238.229: icmp_seq=3 ttl=64 time=1.358 ms
64 bytes from 10.238.238.229: icmp_seq=4 ttl=64 time=1.001 ms
64 bytes from 10.238.238.229: icmp_seq=5 ttl=64 time=1.768 ms
64 bytes from 10.238.238.229: icmp_seq=6 ttl=64 time=1.708 ms
64 bytes from 10.238.238.229: icmp_seq=7 ttl=64 time=1.444 ms
64 bytes from 10.238.238.229: icmp_seq=8 ttl=64 time=1.204 ms
64 bytes from 10.238.238.229: icmp_seq=9 ttl=64 time=1.401 ms
64 bytes from 10.238.238.229: icmp_seq=10 ttl=64 time=1.121 ms
64 bytes from 10.238.238.229: icmp_seq=11 ttl=64 time=1.500 ms
64 bytes from 10.238.238.229: icmp_seq=12 ttl=64 time=1.262 ms
64 bytes from 10.238.238.229: icmp_seq=13 ttl=64 time=1.538 ms
64 bytes from 10.238.238.229: icmp_seq=14 ttl=64 time=2.617 ms
64 bytes from 10.238.238.229: icmp_seq=15 ttl=64 time=3.567 ms
Can anyone confirm if this is the case with your setup too?
-
Nov 20, 2013 1:42 AM in response to ekinfromankaraby MJCXP2,I can confirm the pings are normal when pinging the router faster. I notice no difference when browsing the web compared to my other MacBooks. I figure it is due to some type of power saving implementation that the Broadcom chip uses.
-
Nov 20, 2013 6:57 AM in response to MJCXP2by BanditoB,I thought I'd go ahead and add my experience to the list as well. Perhaps it will be useful to some.
On Sunday, I set up my new 15" Retina MacBook Pro and found that I was having some issues with WiFi connectivity and was definitely experiencing the issue with the erratic ping times. My connectivity problems related to 802.11ac. I could connect with an 'ac' connection if I was right next to my new Time Capsule and could then walk out to a different room where I normally work and it would maintain the 'ac' connection. However, if the connection was interrupted, like when the MacBook went to sleep, it would only reconnect at 'n' speeds. The only way to reconnect at 'ac' speeds was to return to the Time Capsule and let it reconnect there and then return to my work area.
I called AppleCare and they had me change the channels on the Time Capsule to channel 9 for the 2.4 GHz connection and channel 152 for the 5 GHz connection. This solved the 'ac' connectivity issue, but I still had the crazy ping times. They transferred me to another hardware tech and he did some research and spoke with an upper level engineer and they recommended that I take the MacBook into the Genius Bar for a checkup.
Previously, when I first noticed the strange ping times, I thought that there must be something wrong with my network and that there must be a lot of collisions or the like occurring. I verified things on my iMac and a couple of other MacBook Pros and my Mac Mini Server and they all showed that everything was normal with 1 to 2 ms ping responses. All of my equipment has been updated to OS X 10.9 Mavericks, so I didn't suspect it as the culprit. I then reran tests on the new rMBPro and it was still all over the place running from slightly over 1 ms to over 2048 ms in response times! Yes, over two seconds on occasion! I ran some speed tests and throughput was running normally, did some large downloads and didn't have any trouble, so was at a loss to explain the ping times.
I went ahead and scheduled a trip to the Genius Bar on Tuesday afternoon and went in a little bit early for my appointment. After arriving, I found another rMBPro at the store and tested it and lo-and-behold, it exhibited the same crazy ping times. I then went to the Genius Bar and spoke with Jeff who confirmed that I was seeing something unusual with my system and then ran a full diagnostic to verify the hardware, which passed with flying colors. At lunch on Tuesday, I found this thread, so I knew that others were experiencing the same issue and also having confirmed that the store's machine was doing it also, I was much more comfortable in thinking that it is a problem with either software or firmware for the WiFi cards used in the system, so I had Jeff note the problems and then prepared to leave the store and wait for a fix from Apple.
Before leaving, I had some time to kill, so I decided to check a few other systems to see if they had the same ping time issue. I started at one end of the counter and checked an 11" MacBook Air and a 13" MacBook Air. They both did the very same thing! Then I moved on to the 13" MacBook Pros, one with Retina and one without. They both did exhibited the same problem. I'd already checked the 15" MacBook Pro, so I moved on to the 22" and 27" iMacs. Sure enough, they had the same wild ping times. So virtually every computer in the store was doing it.
The only conclusion that I can come to is that they all likely are using the same Broadcom WiFi chipset and there are some definite issues with the drivers under Mavericks. So, first of all the ping problem is widespread, but I'll bet that most people won't notice it as it doesn't seem to impact performance and not many venture into Terminal to check things. It's also readily reproducible, so it shouldn't be hard to track down the cause and develop a fix for it. It's just a matter of time. Whether this issue relates to the connectivity problems that others are experiencing, I can't really hazard a guess, but there could easily be a relationship between the two issues that will get corrected together.
Let's give Apple a bit more time to address this and then see what happens. As always, it's a very good idea to call AppleCare or go to http://apple.com/feedback and leave them a report of the problem. The more they hear about the issue, the more they will pay attention to it.
I hope this helps!
-
Nov 20, 2013 6:53 PM in response to ajaffaraliby ajaffarali,This will sound really strange but yesterday when I purchased the rMPB, I was having issues at office (Linksys) and at home (Airport Express).
Today, woke up and went to the office and was connected for all 8 hours without a single drop. Came back home and streamed a movie in iTunes and no issues at all!!
Freaky. But not complaining as it is working fine now.
-
Nov 21, 2013 12:38 AM in response to ShaneD90by vZwo,Got my new rMBP 15" yesterday, and it seems to have the same issues as the one I returned ...
-
Nov 21, 2013 10:32 AM in response to ShaneD90by Zorkis,Hrm, I've same problem with my quite new MBPr 13. Hmm, is it a hardware issue or just software?
Kinda angry for paying so much for something that can't even keep the ping low.
-
Nov 21, 2013 3:00 PM in response to ShaneD90by casw1000,Hi there, just to throw my experiences behind this as well. I purchased a new Late 2013 rMBP 15" 2.3/16GB/512 and I noticed when connected to my office wireless lan that the wireless was working but the performance was very slow. I also bought a TB > Gig Lan adapter and I noticed an massive speed difference, I went back to the wifi and I noticed further problems.
Whilst I got an IP address from my DHCP assigned access point, I could ping myself but not my default gateway. I also couldn't ping other network devices, yet anything else on the wifi worked. I tried the wireless at a few client sites and got intermittent results, sometimes it works others it doesn't. Massive dissapointment for £2300 (give or take).
I have done some ping tests and post a few results, these were taken from home wireless N network.
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=2.396 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=3.356 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=24.109 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=4.176 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=1.363 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=2.425 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=4.655 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=1.510 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=2.125 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=8.170 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=29.939 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=25.826 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=15.987 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=1.403 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=27.315 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=4.203 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=3.339 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=5.675 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=3.965 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=6.318 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=1.365 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=7.239 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=9.895 ms
64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=16.199 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=7.898 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=6.329 ms
64 bytes from 192.168.1.1: icmp_seq=26 ttl=64 time=1.350 ms
64 bytes from 192.168.1.1: icmp_seq=27 ttl=64 time=12.248 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=64 time=2.784 ms
64 bytes from 192.168.1.1: icmp_seq=29 ttl=64 time=10.799 ms
64 bytes from 192.168.1.1: icmp_seq=30 ttl=64 time=18.839 ms
64 bytes from 192.168.1.1: icmp_seq=31 ttl=64 time=15.164 ms
64 bytes from 192.168.1.1: icmp_seq=32 ttl=64 time=6.331 ms
64 bytes from 192.168.1.1: icmp_seq=33 ttl=64 time=31.285 ms
64 bytes from 192.168.1.1: icmp_seq=34 ttl=64 time=28.049 ms
Request timeout for icmp_seq 35
64 bytes from 192.168.1.1: icmp_seq=36 ttl=64 time=22.079 ms
64 bytes from 192.168.1.1: icmp_seq=37 ttl=64 time=12.444 ms
64 bytes from 192.168.1.1: icmp_seq=38 ttl=64 time=1.321 ms
64 bytes from 192.168.1.1: icmp_seq=39 ttl=64 time=14.383 ms
64 bytes from 192.168.1.1: icmp_seq=40 ttl=64 time=2.551 ms
64 bytes from 192.168.1.1: icmp_seq=41 ttl=64 time=7.931 ms
64 bytes from 192.168.1.1: icmp_seq=42 ttl=64 time=14.202 ms
64 bytes from 192.168.1.1: icmp_seq=43 ttl=64 time=27.478 ms
64 bytes from 192.168.1.1: icmp_seq=44 ttl=64 time=2.651 ms
64 bytes from 192.168.1.1: icmp_seq=45 ttl=64 time=9.677 ms
64 bytes from 192.168.1.1: icmp_seq=46 ttl=64 time=1.452 ms
64 bytes from 192.168.1.1: icmp_seq=47 ttl=64 time=5.039 ms
^C
--- 192.168.1.1 ping statistics ---
48 packets transmitted, 47 packets received, 2.1% packet loss
round-trip min/avg/max/stddev = 1.321/10.111/31.285/8.975 ms
Colin:~ colin
wow, thats not good. I can also get similar results from pinging different websites. I have tried different dns providers which makes no difference. I've had the laptop 7 days now and consider this a real inconvenience. I hope a fix comes soon. Dissapointed!
-
Nov 22, 2013 11:13 AM in response to ekinfromankaraby John Vasileff,ekinfromankara,
Great find! A background "ping -i 0.1 ..." or "ping -i 0.2 ..." on my Late 2013 rMBP 13" completely fixes my latency and dropped packet issues and makes ssh sessions very responsive. I just wish there was a better way to defeat the (apparent) power saving feature.