|
I've got a new intel duo running osx10.4.4 and a powerbook 1g running 10.3.9. Both the machines are side by side running wireless. The conntection to both is 54m and going to a netgear rangemax.
The power book gets a constant 4.4M running speed test from www.nc.rr.com. The intel imac gets 440K. If the imac is hooked directly to the router it then gets 4.4M. Any ideas? I suspect a airport extreme driver problem with 10.4.4. Thanks |
It does sound like a problem with the Airport connection from the iMac.
You might be able to figure out more by doing things like 'ping'ing the router from the iMac. ping ip_address_of_router And maybe trying the Perl script that I supplied in this old thread: http://forums.macosxhints.com/showpo...7&postcount=13 would yield more clues. You could try copying a largish file to and from the iMac. (the idea is to test your Airport network without interaction with the Internet) Especially when used with /dev/null as the destination to factor out the influence of the local hard drive & filesystem, it might tell you something. |
The pings also show the problem as it is 10 times as long for the intel imac as the powerbook. But, I think I found the problem. I'd been using a normal powerstrip, non filtering non surge protceting type. I'd used this same powerstrip for a variety of machines in the past and none ever had a problem. I replaced the powerstrip with a surge protecter/rf filter powerstrip and voila, it's much better now, running at near the same rate as the powerbook. I'll probably get a ups which should have more rf filtering.
|
Well, I thought the problems were over.
Note these ping times The same pattern repeasts regardless of where the ping is directed to. It doesn't happen over ethernet, only airport extreme. The powermac shows normal. 64 bytes from 192.168.1.1: icmp_seq=176 ttl=64 time=1.866 ms 64 bytes from 192.168.1.1: icmp_seq=177 ttl=64 time=1.851 ms 64 bytes from 192.168.1.1: icmp_seq=178 ttl=64 time=1.843 ms 64 bytes from 192.168.1.1: icmp_seq=179 ttl=64 time=1.843 ms 64 bytes from 192.168.1.1: icmp_seq=180 ttl=64 time=1.861 ms 64 bytes from 192.168.1.1: icmp_seq=181 ttl=64 time=1.943 ms 64 bytes from 192.168.1.1: icmp_seq=182 ttl=64 time=249.129 ms 64 bytes from 192.168.1.1: icmp_seq=183 ttl=64 time=204.614 ms 64 bytes from 192.168.1.1: icmp_seq=184 ttl=64 time=156.129 ms 64 bytes from 192.168.1.1: icmp_seq=185 ttl=64 time=104.960 ms 64 bytes from 192.168.1.1: icmp_seq=186 ttl=64 time=3.096 ms 64 bytes from 192.168.1.1: icmp_seq=187 ttl=64 time=1.880 ms 64 bytes from 192.168.1.1: icmp_seq=188 ttl=64 time=1.919 ms 64 bytes from 192.168.1.1: icmp_seq=189 ttl=64 time=1.902 ms 64 bytes from 192.168.1.1: icmp_seq=190 ttl=64 time=1.947 ms 64 bytes from 192.168.1.1: icmp_seq=191 ttl=64 time=2.528 ms 64 bytes from 192.168.1.1: icmp_seq=192 ttl=64 time=247.937 ms 64 bytes from 192.168.1.1: icmp_seq=193 ttl=64 time=203.554 ms 64 bytes from 192.168.1.1: icmp_seq=194 ttl=64 time=152.904 ms 64 bytes from 192.168.1.1: icmp_seq=195 ttl=64 time=104.639 ms |
Anything interesting in the logs? (Run /Applications/Utilities/Console.app to see these)
|
I checked all the logs and nothing. This was right after a complete power cycle.
I tried it on 2 different wireless networks to several different sites, some with dns some with direct ips and all showed the same pattern - 6 good then 4 slow. |
Your previous post about AC-power interference was interesting. Are you sure you've solved that problem?
Maybe try taking the iMac to a different house where you can test the Airport pings? |
Right now it's on a ups which should supply good rf filtering. I'm gonna plug the surge protector into the ups next and see if that does anything but it will be while before I can try that. Where it's plugged into - minus the ups - is the same place the powermac and linux machine were plugged into before and neither had any problem.
When I use ethernet it works as it's supposed to. |
A little mor einformation. Afte it's been up and running for a while it starts getting worse. I'll get 1 or 2 good pings followed by 5 or 6 bad ones plus dropped. I powered off and on then it was back to the 6/4 pattern.
|
What are you using for the Airport setting "Use Interference Robustness"? Try toggling that to the opposite of whatever you have it at now--i.e. if you have that on, turn it off and if you have it off, turn it on.
Trevor |
I tried it both ways and it makes no difference. I've got all bars for signal strength.
|
interface rob on.
64 bytes from 10.82.176.33: icmp_seq=0 ttl=255 time=162.414 ms 64 bytes from 10.82.176.33: icmp_seq=1 ttl=255 time=110.031 ms 64 bytes from 10.82.176.33: icmp_seq=2 ttl=255 time=4.625 ms 64 bytes from 10.82.176.33: icmp_seq=3 ttl=255 time=4.107 ms 64 bytes from 10.82.176.33: icmp_seq=4 ttl=255 time=3.992 ms 64 bytes from 10.82.176.33: icmp_seq=5 ttl=255 time=4.951 ms 64 bytes from 10.82.176.33: icmp_seq=6 ttl=255 time=4.863 ms 64 bytes from 10.82.176.33: icmp_seq=7 ttl=255 time=4.289 ms 64 bytes from 10.82.176.33: icmp_seq=8 ttl=255 time=4.615 ms 64 bytes from 10.82.176.33: icmp_seq=9 ttl=255 time=254.154 ms 64 bytes from 10.82.176.33: icmp_seq=10 ttl=255 time=204.723 ms 64 bytes from 10.82.176.33: icmp_seq=11 ttl=255 time=156.412 ms 64 bytes from 10.82.176.33: icmp_seq=12 ttl=255 time=108.353 ms 64 bytes from 10.82.176.33: icmp_seq=13 ttl=255 time=4.014 ms 64 bytes from 10.82.176.33: icmp_seq=14 ttl=255 time=4.672 ms 64 bytes from 10.82.176.33: icmp_seq=15 ttl=255 time=4.175 ms 64 bytes from 10.82.176.33: icmp_seq=16 ttl=255 time=4.843 ms 64 bytes from 10.82.176.33: icmp_seq=17 ttl=255 time=5.559 ms 64 bytes from 10.82.176.33: icmp_seq=18 ttl=255 time=5.623 ms 64 bytes from 10.82.176.33: icmp_seq=19 ttl=255 time=255.426 ms 64 bytes from 10.82.176.33: icmp_seq=20 ttl=255 time=204.965 ms 64 bytes from 10.82.176.33: icmp_seq=21 ttl=255 time=156.033 ms 64 bytes from 10.82.176.33: icmp_seq=22 ttl=255 time=107.714 ms 64 bytes from 10.82.176.33: icmp_seq=23 ttl=255 time=4.091 ms 64 bytes from 10.82.176.33: icmp_seq=24 ttl=255 time=5.859 ms 64 bytes from 10.82.176.33: icmp_seq=25 ttl=255 time=5.580 ms 64 bytes from 10.82.176.33: icmp_seq=26 ttl=255 time=6.614 ms 64 bytes from 10.82.176.33: icmp_seq=27 ttl=255 time=5.527 ms 64 bytes from 10.82.176.33: icmp_seq=28 ttl=255 time=225.548 ms 64 bytes from 10.82.176.33: icmp_seq=29 ttl=255 time=177.976 ms 64 bytes from 10.82.176.33: icmp_seq=30 ttl=255 time=130.646 ms 64 bytes from 10.82.176.33: icmp_seq=31 ttl=255 time=82.716 ms 64 bytes from 10.82.176.33: icmp_seq=32 ttl=255 time=34.254 ms 64 bytes from 10.82.176.33: icmp_seq=33 ttl=255 time=5.777 ms 64 bytes from 10.82.176.33: icmp_seq=34 ttl=255 time=4.049 ms 64 bytes from 10.82.176.33: icmp_seq=35 ttl=255 time=4.076 ms 64 bytes from 10.82.176.33: icmp_seq=36 ttl=255 time=5.075 ms 64 bytes from 10.82.176.33: icmp_seq=37 ttl=255 time=4.636 ms 64 bytes from 10.82.176.33: icmp_seq=38 ttl=255 time=5.741 ms 64 bytes from 10.82.176.33: icmp_seq=39 ttl=255 time=256.614 ms 64 bytes from 10.82.176.33: icmp_seq=40 ttl=255 time=210.231 ms 64 bytes from 10.82.176.33: icmp_seq=41 ttl=255 time=161.301 ms 64 bytes from 10.82.176.33: icmp_seq=42 ttl=255 time=112.646 ms 64 bytes from 10.82.176.33: icmp_seq=43 ttl=255 time=3.798 ms 64 bytes from 10.82.176.33: icmp_seq=44 ttl=255 time=5.744 ms 64 bytes from 10.82.176.33: icmp_seq=45 ttl=255 time=5.630 ms 64 bytes from 10.82.176.33: icmp_seq=46 ttl=255 time=5.747 ms 64 bytes from 10.82.176.33: icmp_seq=47 ttl=255 time=5.575 ms 64 bytes from 10.82.176.33: icmp_seq=48 ttl=255 time=4.743 ms 64 bytes from 10.82.176.33: icmp_seq=49 ttl=255 time=252.609 ms 64 bytes from 10.82.176.33: icmp_seq=50 ttl=255 time=204.862 ms 64 bytes from 10.82.176.33: icmp_seq=51 ttl=255 time=158.419 ms 64 bytes from 10.82.176.33: icmp_seq=52 ttl=255 time=120.098 ms 64 bytes from 10.82.176.33: icmp_seq=53 ttl=255 time=5.778 ms 64 bytes from 10.82.176.33: icmp_seq=54 ttl=255 time=6.160 ms off 64 bytes from 10.82.176.33: icmp_seq=27 ttl=255 time=5.050 ms 64 bytes from 10.82.176.33: icmp_seq=28 ttl=255 time=4.287 ms 64 bytes from 10.82.176.33: icmp_seq=29 ttl=255 time=5.500 ms 64 bytes from 10.82.176.33: icmp_seq=30 ttl=255 time=5.590 ms 64 bytes from 10.82.176.33: icmp_seq=31 ttl=255 time=5.895 ms 64 bytes from 10.82.176.33: icmp_seq=32 ttl=255 time=4.707 ms 64 bytes from 10.82.176.33: icmp_seq=33 ttl=255 time=262.507 ms 64 bytes from 10.82.176.33: icmp_seq=34 ttl=255 time=216.161 ms 64 bytes from 10.82.176.33: icmp_seq=35 ttl=255 time=166.473 ms 64 bytes from 10.82.176.33: icmp_seq=36 ttl=255 time=118.562 ms 64 bytes from 10.82.176.33: icmp_seq=37 ttl=255 time=6.095 ms 64 bytes from 10.82.176.33: icmp_seq=38 ttl=255 time=9.542 ms 64 bytes from 10.82.176.33: icmp_seq=39 ttl=255 time=5.577 ms 64 bytes from 10.82.176.33: icmp_seq=40 ttl=255 time=5.209 ms 64 bytes from 10.82.176.33: icmp_seq=41 ttl=255 time=4.864 ms 64 bytes from 10.82.176.33: icmp_seq=42 ttl=255 time=4.800 ms 64 bytes from 10.82.176.33: icmp_seq=43 ttl=255 time=258.914 ms 64 bytes from 10.82.176.33: icmp_seq=44 ttl=255 time=211.873 ms 64 bytes from 10.82.176.33: icmp_seq=45 ttl=255 time=168.804 ms 64 bytes from 10.82.176.33: icmp_seq=46 ttl=255 time=119.512 ms 64 bytes from 10.82.176.33: icmp_seq=47 ttl=255 time=4.815 ms 64 bytes from 10.82.176.33: icmp_seq=48 ttl=255 time=4.638 ms 64 bytes from 10.82.176.33: icmp_seq=49 ttl=255 time=8.255 ms 64 bytes from 10.82.176.33: icmp_seq=50 ttl=255 time=6.001 ms 64 bytes from 10.82.176.33: icmp_seq=51 ttl=255 time=5.865 ms 64 bytes from 10.82.176.33: icmp_seq=52 ttl=255 time=4.209 ms 64 bytes from 10.82.176.33: icmp_seq=53 ttl=255 time=252.398 ms 64 bytes from 10.82.176.33: icmp_seq=54 ttl=255 time=208.668 ms 64 bytes from 10.82.176.33: icmp_seq=56 ttl=255 time=112.845 ms |
The ping results are rather curious.
Are there are large number of dropped packets (this shows when you stop the ping)? The time for a ping should depend more on the server (and other nodes in the path) than the originator. Maybe the long times are due to dropped packets. It's possible that using Ethereal would show more details of what is happening. Also try running 'netstat' Another thing that might be interesting is using Apple's "Airport Client Monitor" - available for download from Apple's Airport support site. It shows second by second what the signal & noise is (faster update than iStumbler) and also monitors the bandwidth via pings. http://download.info.apple.com/Mac_O...ementTools.dmg |
Try going to the Apple Airport Support page, and downloading "Airport Management Tools" under Additional Resources.
Run Airport Client Monitor, and let us know what it tells you. Trevor Edit: D'oh! hayne beat me to it! |
Thanks for the hint. I downloaded the monitor it and showed nothing. Not output at all. Is it supposed to work with the intel macs?
I'll try some more tonight. There are dropped packets by the way when the ping times are long I'll see them dropped at times. |
No output at all from the airport monitor. I get the feeling it hasn't been updated for the intel machines. The ping window also show nothing. I did the play pause several times plus tried external pings with no results.
|
I installed 10.4.5 and performance is better. The pings still show the 4/6 pattern but the swings aren't as bad.
|
Me too
I'm having the same problem with my core duo iMac. I noticed lousy network speed, and investigated. When I download a large file, the network activity section of the Activity Monitor shows a square wave which corresponds exactly to the ping pattern you are seeing. I get normal download speed for a few seconds, then practically nothing for a few seconds, then normal speed again. My effective speed is apx 400kbs, whereas my powerbook is getting closer to 3Mbs.
I have no idea what is causing this, but it is NOT fixed in 10.4.5 for me. Anybody have ideas? |
Chadseld, more people are reporting it.
Is there anyway to tell Apple about it? |
Quote:
|
Thanks, seems there are several others with the same problem.
|
Same AP Extreme issue here
I've got the exact same problems with my 20" DuoCore. Pinging any site shows the same issue of fast then verrrry slow transfer of packets but nothing dropped. Speed tests at Speakeasy show it anywhere from 700 kbps to 1600 kbps, and that's on cable modem. I have a 17" imac G5 sitting right next to it that runs around 4000 kbps.
Apple customer support says nothing's wrong because I can connect to the internet and receive email. Hopefully Apple is aware of this problem and has a fix in short order. |
Hi,
There is something definately wrong with the networking... the symptoms are exactly the same on the new 20" Intel iMac my partner just bought. Any update on fixes? -j |
Airport problems on Intel Mac Minis
Many people (including myself) had this problem. See link in the Apple support forums here.
My setup uses Airport Express as the Wireless Router (connected to the Cable modem) and was setup initially in 802.11g mode using WPA2 Personal security. My G4 iBook as well as another PC was able to connect without any problems and with full signal strength and were consistently showing expected connection speeds (> 3 Mbps). However, the Intel Mac Mini (Solo) had connection dropouts as well as very slow connection speeds (< 300 Kbps). After fiddling with all Airport Express settings, finally fixed the issue by changing the Airport Express (router) mode to 802.11b! After this change, the Mac Mini is not dropping any connections, signal is at full strength, and connection speed has jumped back to ~ 3 Mbps. Maybe the driver/Airport H/w within the Intel Minis have a problem (firmware?) with 802.11g at this point. |
Here's your solution to weird packet loss periodic ping times and generally slow wifi
The issue is not to do with g or b support (a happy coincidence for some), but rather the implmentation of IPv6
This is very new and clearly not there yet in OSX on the intels (most of the world is on IPv4 anyway) This was doing my head in for a while, but now have a proper fast connection and no constant rebufferings when watching films or streaming iTunes. To Solve: Go to network preferences for your Airport, Select TCP/IP and the button Configure IPv6... Turn it off... et voila - a fast connection once more... Hope you all see this as I was ready to reopen the dell or thinkpad - god forbid! Cheers Tarquin |
Turned off IP6 - still facing issues in 802.11g mode
Turned off IPv6 as per the suggestion above. Still facing the same issues in 802.11g while connection remains fine in 802.11b mode. Maybe it's just my mini :confused:
|
Try opening your Airport Utility application located in Applications > Utilities. Choose the base station you want to configure and then under "Airport" click "wireless settings" and turn interference robustness on.
It worked for me. I suddenly got this problem a week or two back. Could be when installing the latest Security Update - not sure. Anyway my connection was suddenly very unstable. And often it didn't work at all even though I had four bars in the Airport Icon. |
Quote:
|
KisMAC running a passive mode scan reveals this must be a driver bug
You can stablize your wireless connection while KisMAC (kismac-ng.org) is running your Airport Extreme card in passive mode. This shows that this issue is a software issue (driver) and not a hardware issue. This problem is also evident in the Bootcamp drivers for Windows running on these.
Do the following and you will see what I mean.
I have duplicated this issue on all of the Macbooks (2009 models) I have touched. These are using Leopard and Snow Leopard. Same issue. I have duplicated this issue on B networks, G networks, WPA and WPA2 PSK, WPA and WPA2 Enterprise (with 802.1x authentication using PEAP), Hidden and Broadcasting SSID's, different branded Access Points (Apple Airport Extreme, Sonicwall Sonicpoints, 2Wire). The wireless adapter in this model apparently uses a broadcom based chipset that uses a software controlled MAC layer (Media Access Control). I suspect the issue lies here somewhere. I have been trying to get these to integrate into an existing Active Directory network, and this wireless issue is causing so many headaches.. If this connection would be stable, I do not think we would have such a difficult time. But as it stands... We wait and search for a resolution. |
| All times are GMT -5. The time now is 07:51 PM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
Site design © IDG Consumer & SMB; individuals retain copyright of their postings
but consent to the possible use of their material in other areas of IDG Consumer & SMB.