This discussion is locked
Satoru Murata
Level 1 (15 points)

Q: Slow Wireless LAN in Leopard

All right, I've spent the past 12 hours (on and off, of course) looking through all the threads in here, doing a lot of experimentation, and a bunch of clean installs and whatnots, and I've decided to start a new thread, since in many of the said threads, some people seemed to have similar issues, but the other issues in the same threads seem to be different problems, and it just becomes confusing when you try to trouble shoot something and people are talking about different problems.


So, this thread is specifically for people who satisfy these criteria under Leopard:

1) You're having issues with very slow file transfers in your *local network* when at least one end is connected wirelessly; that is to say, when both ends are connected to the router via ethernet, you see no problem at all.

2) Your wireless connection doesn't display problems when connecting to the internet.

3) It is not specifically an 802.11n issue; i.e., the problem can be duplicated when in Mixed b/g only mode and/or using an 802.11g router.

4) It's not a router connection issue; i.e., your wireless connection isn't being dropped, and you are able to find your AP and connect to it without any problems.




So basically, that more or less sums up my problem. My equipments:

MacBook Core2Duo 2.2GHz, 802.11b/g/n, OSX 10.5.2
iMac Core2Duo 2.13GHz, 802.11b/g/n, OSX 10.5.2
Router 1: TRENDnet TEW-631BRP (Draft N router), H/W V3.0R, FW v.1.0.3.7
Router 2: NETGEAR WGR614 v.5 (g), FW v.1.0.3_1.0.3

Internet: RCN Cable, 20Mbps/2Mbps


In my usual setup, the iMac is connected via Ethernet and the Macbook is connected wirelessly.


I know that this is a Leopard problem, but I'm not so sure it's a 10.5.2 specific problem. Let me explain.

I'd been using the TRENDnet more or less happily for the last couple of months. My iMac and Macbook have been in sync in terms of Leopard versions, so I know things were OK till last night when I first noticed problems. Transferring a large video file from the iMac to the Macbook would start off fine, then really slow down, and finally almost completely halt. Naturally, I blamed 10.5.2.


After trying all the different "fixes" in the Leopard/network related threads with no avail, I tried booting my laptop into Tiger (10.4.11) installed on an external HDD. Voila, wireless file transfer speed is fast at around 8MB/sec (obviously using N). I did a fresh install of 10.5, and the speed immediately dropped down to 1-2MB/sec, although not necessarily stalling. Then, updating to 10.5.2 slowed it down more, and now the transfers will sooner or later almost completely stall.


Again, I tried all the suggested remedies (use b/g Only mode, adjust RTS/Fragmentation thresholds, use WEP instead of WPA, delete all the Network Services in System Preferences -> Network, etc., etc.). Nothing helps. I tried swapping the router to an older Netgear (802.11g/b), and it's the same deal, so it's not a router issue.


A definite characteristic is that the transfer seems to stall after a certain period of sustained transferring; i.e., this will usually only happen when transferring large files (>200MB). If I were to download a folder with 600 JPEG files @ 1MB each, there won't be a problem, and the transfer rate will be pretty fast (although not as fast as under Tiger @ 7-8MB/sec), and it won't stall. It's only when I try to transfer big video files, etc., that this problem occurs.



If you are having similar issues, please share your experiences, suggest remedies, offer insights. I will try to answer any question you may have and that I may have missed to address.


PLEASE: if your symptoms are different from what's listed up there, please try to refrain from posting here, unless you are absolutely certain that the issues are related. Thanks.

iMac 20" Core2Duo 2.13Ghz/ MacBook 2.2 GHz Superdrive (White), Mac OS X (10.5.2)

Posted on Feb 14, 2008 12:39 AM

Close
Satoru Murata

Q: Slow Wireless LAN in Leopard

  • All replies
  • Helpful answers

first Previous Page 4 of 11 last Next

  • by brian163,

    brian163 brian163 Feb 20, 2008 4:47 AM in response to Satoru Murata
    Level 1 (28 points)
    iTunes
    Feb 20, 2008 4:47 AM in response to Satoru Murata
    (I wrote this somewhere between 3-4am yesterday but fell asleep for a got a chance to post it. I'll have to give the "delay_ack hack" a try and report back later tonight.)

    THANK YOU Satoru for starting a separate thread on this specific problem. For the past 9 hours (almost to the minute) I had been tearing my home Apple Extreme Base Station (Snow)/Airport Express WDS wireless network apart (and hair out) trying to determine why my local transfers were starting off healthy and then dropping off suddenly.

    Slowly through the process of elimination I determined that the simplest setup of just an AEBS (Snow) or Airport Express and one MacBook client (10.5.2) exhibited the strange behavior with a test file larger than a few MB (my test file was 50MB, which started this whole wild goose chase this afternoon). The file copy between the wireless client and the ethernet wired "server" (a G5 tower also running 10.5.2) would start at a "burst" of 2-3MB(ytes)/s and then suddenly drop and remain at 20-30KB(ytes)/s. And if I tried to stop the copy, I'd often suffer several minutes of the "spinning cursor of boredom" until the Finder would respond to the request.

    Then I tried the same file copy test from a Powerbook Alum. G4 and VOILA, the sustained file transfer hovered in the 2-3MB(ytes)/s rate most of the time.

    Which leads me to a few observations/confirmations that I thought would be useful to your thread:

    1) When I repeat the file transfer test on both wireless client machines to the wired machine many times in a row, I notice that the 10.5.2 machine will either start well and drop off or just start off poor and stay poor. While on the 10.4.11 machine it will always start off well. And while there may be an occasional drop, it is able to bounce back up to the 2-3MB(ytes)/s throughput I would expect to see. (In other words, the 10.5.2 client isn't "recovering" from a drop.)

    2) If I mount the 10.5.2 wireless client (MacBook) from the wired G5 "server" and perform the same file copy (in the same "direction") the transfer rate is 2-3MB(ytes) generally sustained (similar in behavior to the 10.4.11 client to the "server"). This is true even if I start a simultaneous copy from the 10.5.2 client first and the rate had dropped off. In other words, it's the 10.5.2 client's send rate that is specifically effected, not the receive rate.

    3) If I mount the 10.5.2 wireless client to the 10.4.11 wireless client (or vice-versa) they both result in a sustained transfer of 1.8-2MB(ytes)/s-- which I believe to be normal since they would both be talking to the access point at the same time reducing overall throughput a bit.

    I also tested an 11Mb (802.11b) Powerbook Titanium G4 running 10.4.11 and while throughput was only 400KB(ytes)/s it was sustained. Performing this test also caused the PB Alum's (10.4.11) throughput to drop to 802.11b speed during the copy as expected behavior of a mixed network. But it would return to normal speed if I stopped the PBT's copy. However, the MacBook (10.5.2) client's speed usually started poor as noted above (20-30KB(ytes)) and would drop off to 4-5KB(ytes). So changing speeds on the access point does not "trick" the 10.5.2 client back to normal speed.

    I also test on a MacBook Pro running 10.5.2 and observe the same bad behavior.

  • by Satoru Murata,

    Satoru Murata Satoru Murata Feb 20, 2008 6:42 AM in response to JOHN ALBERGO
    Level 1 (15 points)
    Feb 20, 2008 6:42 AM in response to JOHN ALBERGO
    Great, the first possible "solution" to the problem!

    I tried the Terminal command first and seeing that it didn't cause any problems, installed the startup item. I'm trying file transferring right now and it seems to have made it better, although not a complete fix.

    I'm transferring a 1GB file from my Macbook to my iMac (which, for various reasons, is now also wirelessly connected to my router) and the transfer rate is around a sustained 2MB/sec. Not even close to what this 802.11n router should be able to achieve (9-10MB/sec) but certainly not crawling to a near-stop either.

  • by JOHN ALBERGO,

    JOHN ALBERGO JOHN ALBERGO Feb 20, 2008 9:18 AM in response to FlashYourWeb
    Level 2 (239 points)
    Feb 20, 2008 9:18 AM in response to FlashYourWeb
    GDL3D wrote:
    Thanks Troy. Yes, it does mention in the comments that it's useless for PPC. This is soooo frustrating. When ever I am using Dreamweaver or Photoshop with files and directories over the wireless network, I get sooo many hangs during work. File transfers cause the same issue. I am going to have to get my Admin involved to diagnose what is going on. If i find out anything i will report back.


    I recommend you try it. Don't get too hung up on the comments from the original blog entry, as it is from Feb 2006. It is possible that the bug that was introduced with the first Intel versions of OS-X has cropped up and been moved into all versions. delayed_ack is not a cpu dependent setting.

    In a nutshell, ACKs are signals that the machines send each other to confirm they have received data packets, to confirm that the other side KNOWS they have received the packet, etc.. This is part of the "guaranteed delivery" aspect of TCP/IP. If both sides don't agree that the data was delivered, then it is sent again.

    What programmers realized was that it was a bit wasteful to "spend" a data packet just to send the very small ACK signal. And so they devised a protocol where both sides agree to wait and let the ACK ride along on a subsequent data packet. But it will only wait so long and if no data packet happens to come along it will go ahead and send the ACK by itself, etc., etc., There's a lot of logic behind making this work. But if well-implemented it does better utilize the bandwidth of the connection.

    But if one side or the other isn't properly delivering those delayed ACKs it can cause problems. There are time limits and if the ACK is not received in time, retransmits and cleanups are needed.

    So, to summarize it, delayed_ack is there to make the transmission more efficient. But you won't break things by turning it off. You may not get the ultimate in throughput, but a modest decrease in throughput is preferable to the unbearable slowdown I was experiencing previously.

    Just remember that you have it in place, and when Apple fixes the problem you can remove the script from your startup items. The system builds these settings from its own configuration file when you boot up, so you will then return to the settings that Apple put in place.

  • by FlashYourWeb,

    FlashYourWeb FlashYourWeb Feb 20, 2008 10:35 AM in response to JOHN ALBERGO
    Level 1 (0 points)
    Feb 20, 2008 10:35 AM in response to JOHN ALBERGO
    John. Thanks very much for the advice.

    It works perfectly now using it on my Albook G4 and my Dual G5. It looks like this is a universal fix at least for the moment.

    I installed the startup item and also manually performed the following in terminal.

    sudo sysctl -w net.inet.tcp.delayed_ack=0


    Everything is now all speedy again, and I am hoping I won't drop my afp mounts too.

    I'll keep you posted.

    Thanks to everyone for commenting on this.

  • by Bryan M,

    Bryan M Bryan M Feb 20, 2008 2:05 PM in response to Satoru Murata
    Level 1 (20 points)
    Feb 20, 2008 2:05 PM in response to Satoru Murata
    First, thanks to Satoru for posting this specific topic. I've been searching everywhere over the past couple of days for some insight into this issue.

    I was beginning to wonder if this was a protocol or TCP issue when I noticed that copying over SCP and SFTP was much faster than copying over AFP and SMB. Just as I was testing this, I read the messages about the old TCP ACK problem.

    I can confirm that using this fix has helped significantly in copying files between machines running 10.5.2 via AFP or SMB, although transfer speeds are still not quite as fast as expected.

    Thanks to John for reminding us all about this old issue and providing the fix for it.

  • by Byzanti,

    Byzanti Byzanti Feb 20, 2008 3:56 PM in response to Bryan M
    Level 1 (0 points)
    Feb 20, 2008 3:56 PM in response to Bryan M
    While I've had a Mac(Book) for all of about 10 hours, I'm afraid this solution doesn't work for me. Internet etc is fine, but local transfer goes at (a rough estimate) of 1mbyte/s, and it connects at 54mbit/s. I've tried the terminal code, but there's no change. Would it make a difference that I'm transfering from PC to Mac, rather than from Mac to Mac?

    Many thanks

  • by Shawn Parker1,

    Shawn Parker1 Shawn Parker1 Feb 20, 2008 8:02 PM in response to Byzanti
    Level 1 (125 points)
    Feb 20, 2008 8:02 PM in response to Byzanti
    Another success here. While not introducing blazing fast transfers, it is significantly better.
    Over G wireless I'm getting about 2MB/s transferring a single large file.

    So I think this solves just part of a larger problem.

  • by wethackrey,

    wethackrey wethackrey Feb 21, 2008 9:38 AM in response to Satoru Murata
    Level 1 (0 points)
    Feb 21, 2008 9:38 AM in response to Satoru Murata
    I have the identical problem. A MacBook Pro (Core 2 Duo) connected via an 802.11N connection (Linksys). The problem predates 10.5.2. It began when I upgraded to Leopard. Currently the MacBook Pro and one of the other Macs is at 10.5.1. The third Mac on the network (a gigabit network) is at 10.5.2. Trying to move a file between the MacBook Pro and either of the other Macs takes a LONG time. The "Preparing to copy" dialog cogitates on the move for as much as a minute before the transfer begins. This is the case no matter what size the file is. When the transfer finally does start it is very slow. A 20MB file can take two minutes. By contrast, a 20MB file being transferred down from the internet comes across at full cable modem speed.

    This is more than a bit frustrating. The network is virtually unusable as a LAN at this point.

  • by JOHN ALBERGO,

    JOHN ALBERGO JOHN ALBERGO Feb 21, 2008 9:50 AM in response to Bryan M
    Level 2 (239 points)
    Feb 21, 2008 9:50 AM in response to Bryan M
    You're quite welcome.

    I'm including a link to an interesting article. I don't have the inclination to muddle through tcp dumps to see if this is actually the issue, but it sure smells like it. But in any case, it's an interesting read on how there can be insidious problems with things that we take for granted and we assume that they "just work". I read elsewhere that Nagle himself suggests an addition to the standard TCP protocol to address this issue, and states something to the effect that it has been "giving people headaches for 20 years"!

    http://www.stuartcheshire.org/papers/NagleDelayedAck/

  • by silverburn,

    silverburn silverburn Feb 21, 2008 12:26 PM in response to Satoru Murata
    Level 1 (0 points)
    Feb 21, 2008 12:26 PM in response to Satoru Murata
    Yes, I had this problem too...

    New 3rd gen macbook (10.5.1) to replace a 1st gen macbook. Symptoms are:

    1. Initial wifi speeds for local transfers were 2mb/sec (g) and 7mb/sec (n)
    2. after a random period of time (10 seconds - 3 minutes), this would drop to 30-35k/sec
    3. stopping wireless connections & waiting for 15 seconds and restarting returns you to step 1

    Tried all the recommended step (fixed channels, different routers, no IP 6, tearing hair out, etc etc)

    I swapped in my old drive (10.4.10) in the new macbook, and got normal network service, no matter how much I pounded it. APPLE....YOU ARE A SHAMBLES....

    I'm running the delayed ack fix, and currently getting 1.6-1.7mb/sec. It's not full "N" speed, but frankly I'll take a stable 1.5mb/sec over 10k/sec any day, and until Apple fixes this!

    You guys rock who noticed this.

  • by Satoru Murata,

    Satoru Murata Satoru Murata Feb 21, 2008 12:37 PM in response to Satoru Murata
    Level 1 (15 points)
    Feb 21, 2008 12:37 PM in response to Satoru Murata
    Thanks everyone for your continued contributions to this thread. It's quite amazing how almost everybody here is experiencing nearly identical issues (although part of that likely has to do with the fact that I was a little Nazi about who may or may not post in this thread upfront


    With these stories coming in, I'm starting to wonder if there is anybody out there that has similar/identical setups as us but is not seeing these issues. I.e., people who have 10.5.2 running on multiple Macs connected wirelessly (preferably to an 802.11n router) and get local file transfer rates in the 7-10MB/sec range. Hmm...

  • by pbw,Helpful

    pbw pbw Feb 21, 2008 6:52 PM in response to Satoru Murata
    Level 1 (70 points)
    Feb 21, 2008 6:52 PM in response to Satoru Murata
    I believe I have the same setup and am NOT seeing the problem. I have a 1st gen Macbook (10.5.2) connected to an Airport N station via ethernet. My Nov2007 MacBook (10.5.2) connects via 802.11n (5.8GHz N-only mode).

    Two nights ago, I was copying from the newer Macbook to the older Macbook. I was seeing very choppy transfer speed (as low as 20Kb/s). Just as the transfer was almost complete, the speed jumped to 4 MB/s. Prior to 10.5.2, I had been consistently able to transfer 10-11 MB/s.

    The next day, I found this thread. But when I got home from work, I couldn't replicate the problem. Tonight, it's still working fine. I'm certain I didn't change anything. So I'm chalking up the choppy transfer to temporary interference.

  • by donaciano,

    donaciano donaciano Feb 21, 2008 11:57 PM in response to JOHN ALBERGO
    Level 1 (5 points)
    Feb 21, 2008 11:57 PM in response to JOHN ALBERGO
    Fixed it for me, THANKS!

  • by Murpheous,

    Murpheous Murpheous Feb 22, 2008 7:39 PM in response to Satoru Murata
    Level 1 (0 points)
    Feb 22, 2008 7:39 PM in response to Satoru Murata
    The suggested workaround solved my iTunes network lag problems that I discussed previously. This makes the wait for the real fix from Apple much more bearable. Big thanks!

  • by Alan Somers,

    Alan Somers Alan Somers Feb 23, 2008 7:38 AM in response to JOHN ALBERGO
    Level 6 (9,349 points)
    Feb 23, 2008 7:38 AM in response to JOHN ALBERGO
    Add me to the list. A large movie file transfer from my server to my MacBook Pro would go along just fine for 150MB or so and then slow to a crawl. I tried the delayed_ack trick while a stalled transfer was in progress and the transfer immediately accelerated to normal speed.
first Previous Page 4 of 11 last Next