![]() |
real-world performance
Quote:
See http://www.pcworld.com/news/article/...83,pg,2,00.asp for some measurements that show a maximum transfer rate less than 5 Mbps with WEP off. Enabling WEP will lower the transfer rate significantly. If you are interested in why the actual rate is lower than the nominal rate, see this article that calculates a theoretical maximum rate of 5.6 Mbps for 802.11b: http://www.oreillynet.com/pub/a/wire...hroughput.html So, your calulation is off by a factor of at least 11/5, which brings the minimum time for transfer of that 300 MB file up to 8.4 minutes. I.e. his 30 minute transfer time is only a factor of 4 slower than the best he could expect. So yes, there likely is something that could be improved in his setup, something that is slowing it down, but the problem isn't quite as big as it might seem. I also note that you shouldn't expect more than about 50% of the nominal transfer rate for Ethernet networks either. |
Quote:
|
Cool, thanks hayne. It's been a while since I dusted off the calculator. :) I suppose if I'd thought about it I would have realized that 11 Mbps was the optimal speed.. but anyway, I concur that there's something amiss here.
Bustthis, you really should test without any apps running on either machine and see what kinda speed increase we get (if anything noticable at all). At this point I think you've become a lab rat for 802.11b transfer rates. :) |
no apps running on either machine after a restart tried to copy a 350 mb folder and it took 49 mins!!!
i'm lost at this point... could it be a bad ethernet cable going from the abs to the cable modem? what can i do!!! |
As far as I know (correct me if I'm wrong) the cable modem has nothing to do with this. The traffic between machines should be passed (repeated) only through the base station, so cabling should be an issue.
|
Hmm, do I understand the situation correctly? You are trying to transfer files between your two machines, through and airport extreme base station, and these machines are communicating (however slowly) through the airport connections, right?
If that's the case, I would assume (perhaps incorrectly) that the ethernet cable connecting the aebs to the cable modem is not a factor. I would be interested to know what sorts of transfer rates you get when you transfer from machine to machine. I realize that JDHorner gets bad rates even here, so maybe I'm just a curious bird. But hey, that's me. Best, darin [edit]Ya, what Yellow said.[/edit] |
your right and that makes sense...
any ideas on what i could do at this point? |
I'm just musing here, so take what you will---
Would it be at all useful to try the same transfer with the computers wired to the base station, so that they were transfering through ethernet cables as opposed to through airport connections? Is this possible in your location? I'm wondering two things: 1. could you isolate this problem to the airport connection and 2. is there perhaps, despite Apple's claims, a less than idea connection made when you combine an older airport card with a newer extreme base station. Again, just musing, and I don't have a base station, so I don't know too much about them. I hope that somebody will correct my errors. Best, darin |
my numbers
Prompted by this thread and another one about slow network transfers between Mac & PC, I spent some time to measure the performance I get on my home network.
The network: 1) MacSense router connected to DSL "modem". The switching side of this box does "fast" Ethernet: 100 Mbs 2) Airport 802.11b basestation, configured to act as a "bridge" to the router. 128-bit WEP is enabled. 3) Cat-5 cable between all nodes The computers: A) iBook 600 Mhz, running 10.2.6 (connects via Airport and/or Ethernet to the router) B) HP Pavilion PC, 800 Mhz, running Windows ME (connects via Ethernet to the router) In the following experiments, I mounted a shared folder from the PC on the iBook via SMB ("Connect to server" in the Finder) and copied a 33.5 megabyte QuickTime movie file back and forth, deleting the copied file after each test. When I disconnect the Ethernet cable from the iBook (so that it is connected only by Airport), copying a 33.5 MB file from the iBook to the PC takes about 2.5 minutes - i.e. 150 seconds. That translates into a transfer rate of 1.9 Mbps (to be compared to the nominal 11 Mbps of 802.11b). When I turn off Airport on the iBook and reconnect the Ethernet cable, it takes only 21 seconds to copy that same file. That translates into a transfer rate of 13.4 Mbps (to be compared to the nominal 100 Mbps of "fast" Ethernet). One thing to note: I have turned down the MTU on my iBook's Airport card to 1384 since anything higher seems to give trouble when sending larger email messages via my DSL connection. Presumably I would get a bit better Airport transfer rate if my MTU was at the default 1500. I might be trying to improve my network speeds if my configuration were stable. But, except for my iBook, most of my machines (there are more than the 2 I mentioned) are turned off or hibernating most of the time - to cut down on the noise. So my typical transfer time is dominated by the time to boot the machines! |
dhayton you bring up a good point here. or, at least, a good idea. i was excited to think that perhaps it was the fact that there was at least one airport extreme device in the mix that's the culprit. (both my basestation and the 15" are NOT extreme. only the new 12" AlBook is).
but then i realized that the 12" iBook that this new computer just replaced was also non-extreme. so even back when everything was only 802.11b i still had the same problems. i'm going to bed now, but will hopefully be able to test some of the suggestions here some time tomorrow. my first test will be to disable WEP completely. as a side note, and i never even really noticed it before, does anyone know what the option to "use interface robustness" in the airport.menu item actually DO? |
keep in mind that file transfers are greatly affected by the disk subsystem itself. It tends to be a major bottleneck. If you want to eliminate issues with the network, you need to test the connection by using a program such as "ttcp" and do a memory-to-memory transfer of bytes, omitting disk involvement. you should do this in one direction and then in the other. something like ttcp lets you set the buffer size of the socket. experimenting with this will tell you where the bottleneck is, if any, on transfer size. Note that programs that doen't allow u to set transmit/receive buffer sizes make the problem harder.
laptop disks tend to be slower and less performing than SCSI,fast IDE etc. Also the program used to transfer a file has inherent limitations due to over head of the protocol it uses. The ability of a system to buffer data in front of the disk subsystem is also a factor. that's why some disks have large caches to help, but small writes can hurt this. In benchmarking systems, I tend to use something like ttcp to help "tune" tcp/ip and when I think I have that as best I can, I then look at the disk syubsystem. Systems that have raided disk will obviously write more efficiently than trying to pound data onto a single disk, especially a laptop. your mileage will vary. |
diagnostic tools
There is a newer tool 'iperf' which is claimed to be better than 'ttcp'. Version 1.6.5 is available via fink but a newer version is available from the iperf web site:
http://dast.nlanr.net/Projects/Iperf/ I haven't tried it yet. That web site led me to a page with a very interesting analysis of OS buffer sizes and how they prevent us from attaining the maximum bandwidth available on high-speed networks: http://www.psc.edu/networking/perf_tune.html And that web site linked to a useful diagnostic tool (Java applet + specialized back-end server) that can tell you if your Internet connection is suffering from misconfiguration: http://miranda.ctd.anl.gov:7123/ Even though you have been talking about LAN performance, this tool might give some clues since it of course tests part of your LAN in getting to the Internet. |
| All times are GMT -5. The time now is 07:41 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.