25148 Views Previous 1 … 3 4 5 6 7 … Next 163 Replies Latest reply: Oct 29, 2008 7:49 PM by younker_dl Go to original post
Much props to you for starting this thread.
I have the same problem and am going mad. I have apple care and will try and call them in the morning to find out if they can help me. This is doing my head in. I have a dlink dir 635 router and have lowered the threshold as before I lowered it i could not connect to the wlan. I could get an ip but could not contact any other host. how i can. internet speeds are about 1.6MB which is normal. lan speeds are about 100k which *****. i have tried 802.11n and 802.11g. neither work well.
Thanks for your report, it is very helpful. This suggests that this is NOT a universal problem with the OS, and therefore the reason behind what all of us are seeing must lie somewhere else.
One thing I (or someone) would have to try: boot 2 computers into a completely fresh copy of OS 10.5.2 and see if this problem persists. If it does, then the problem is most likely to be something physical (as in hardware as opposed to software), or environmental (e.g., interference).
Let's continue our examinations.
I got the same issue after applying the 10.5.2 update. Uploads would start at full speed then after 3-5mins decay down to 30KB/s (from 150KB/s). This happened over wireless and ethernet. I tried adjusting delayed ack and several other settings, nothing worked. Finally downgraded to 10.5.0 and now uploads are fine again.
I've had the same behaviour on my network since Airport Firmware 7.2.1 (AEBSn) 6.3 (AEX) and Tiger 10.4.9 which followed through into Leopard (despite 3 clean installs). I have spent literally days on end trying to debug the performance issue using all sorts of set-up arrangements including using the base stations as DHCP router with 3rd parties in bridge mode (to negotiate ADSL2+) and continue to draw a blank. My conclusion (process of elimination) is that both OSX airport drivers and Airport Firmware require a fix from Apple. Meanwhile I'm trying out John's suggestion with fingers crossed.
Apple tested hardware list:
AEBSn x 2
3rd Party routers tested:
Draytek Vigor 2820
Zyxel P660HW T1
See this post for the first suggestion I've read so far as to what the underlying problem might be in 10.5.2 and why turning off delayed ACKs may be working as a band-aid solution:
I had exactly the same problem. Eventually, changing the WLAN channel solved my problems: I was using channel 4 for many years and did not have any problems until I updated to 10.5.2.
Now I changed to channel 8 - and it works flawlessly, again! This is somehow strange, as I cannot find any router, which uses my old channel.
I would encourage everybody to try different channels. Maybe this will help someone.
Message was edited by: Graefe
I'm no expert in this stuff, but it sounds to me like this is a case where specific performance issues in the source or destination could trigger the problem. The problem then cascades into something so bad the user sees it. With a different source or destination, or perhaps even some difference we haven't fathomed yet in the wireless hub, the problem might not start or might be minor enough that the two ends recover before the user notices anything is wrong.
Since we are seeing this almost exclusively in wireless setups, I'm assuming Apple made some change in 10.5.2 which made it more sensitive to the START of problems in the transmission (and more specifically, to large data transfers that are outbound from the 10.5.2 machine). And if this "silly windows" thing is really what's going on, then that triggers the cascade of window size reductions.
I like this explanation because it would also explain why turning off delayed ACKs is not getting people back the full transmission speed they had before. The problem recovers, but then recurs, and you are wasting time with multiple recoveries.
All of this is guess-work at this point. I'm hoping the guy who posted in the other thread comes back with how he saw increased packet counts and what he knows about what that means for improperly reduced window sizes.
EDITED TO ADD: The difference could even be that some wireless setups see occasional interference which triggers the cascade of window size reductions, whereas others don't. I'm not sure how long it takes for the windows to get too small in this scenario, but there could be an element of how large the transfer is and how likely it is that an interference glitch will happen at some time during that transfer and initiate the problem.
Message was edited by: BobP1776
This is off-topic from this specific thread but I found that the newer 802.11a/b/g/n Airport cards are much more sensitive to 2.4Ghz interference than older 802.11b/g cards:
Again, this clearly isn't the root cause for this problem but it could be confusing the issue.
Unfortunately delay_ack 0 hasn't worked for me, infact it made file transfers (scp -r etc...) on my local network very unreliable. I guess there isn't a single answer to these airport issues. I'm hoping Time Capsule will prompt the release of new firmware for Airport, it can't be too far away I hope.
thanks for bringing this focussed thread to life!
have been following this after i found it 3 days ago and just wanted to add my five cents which i haven't seen detailed out here yet:
it seems there's a significant difference between WRITING and READING speeds while copying over wireless between two macs in leopard.2.
writing in .2 hasn't really been a problem but as pointed out many times here, reading shows the symptoms described above. start off fine, slow down, slow down significantly and then stop w/ error.
the ACK "band-aid": while now at least allowing successful copying for me, seems to have significally reduced (pre .2) speed. while reading a 700MB file took "about 2 minutes" before .2 it now takes "about 6 minutes".
can anyone confirm this experience?
haven't tried the "channel 8" thing yet.
I hope I don't repeat anything that has already been said here, but I know the Satoru wanted to hear from everyone with the same problem, so here I am!
G4, MacBook, both .11g connections to a .11g Netgear router. Internet and other protocols tried, high throughput. AFP connections run at between 20-70KB/s.
Then I ran this script (the delayed ACK thing):
When I installed it on my MacBook, RX improved but TX was still slow. Installing on the G4 then made all RX and TX improve. So I'm assuming the script helps transfers in an incoming direction.
I'm guessing this is a hack - but is this as fast as a proper solution?
It is almost definitely a bug in handling delayed_ack. I tested both Leopard and Tiger, setting delayed_ack=0 (off) and delayed_ack=3 (default .... "detect streaming" according to Darwin source code).
With default i get about 2Mb down and 256Kb up (50% of my rated connection speed). With delayed_ack=0 (off) I get about 4Mb down and 400Kb up .. close to the advertised line speed. I filed a Radar on it.