On Thu, 30 Dec 2004 11:06:56 +0100, meATprivacyDOTnet <(E-Mail Removed)>
wrote:
>On 12/29/04 6:32 PM, Jeff Liebermann wrote:
>
>> 1. Please disclose the exact command line and non-paraphrased output
>> from IPerf. What buffer sizes did you use? Were you testing TCP or
>> UDP? (UDP is somewhat faster). Between what two operating systems
>> (Linux, Unix, Windoze, etc)?
>
>The first laptop (Dell Inspiron 8000 - P3 1Ghz - 512MB RAM) is running
>Windows XP Professional SP2, the other laptop (Apple PowerBook 17" - G4
>1.5Ghz - 2GB RAM) is running Mac OS X Panther (10.3.7). There is no
>firewall software enabled on the laptops.
Ok. Those are fast enough to do a decent test.
>I ran the utility in server mode on one laptop (iperf -s) and in client
>mode on the other one (iperf -c 192.168.0.x). I didn't use any special
>option (except for running the test for more seconds than the default
>setting). I think the utility does a TCP test by default, using the
>default OS TCP window size.
Yes, it's TCP by default. Default's the problem. IPerf starts with a
very small buffer size (50KB?) which will be REALLY slow. Try:
Server Side:
iperf -s -w 500k
Client Side:
iperf -c -w 500k
500k is probably too large, but it's what I use for a first
approximation.
Also, be sure to run:
iperf -s -m
and see if it complains about MTU discovery failing. What's the MSS
(or MTU) size reported? If it's stuck with small packets, it's gonna
be slow.
>I don't have the iperf output handy now, but it was about 12Mbps.
Do you really expect a specific answer without supplying any details?
Try answering some of the questions in this newsgroup and you'll
notice that over half the posted questions don't bother to supply any
numbers or details. Apparently, it's a common expectation.
>I did
>serveral tests, in both ways: from laptop 1 to laptop 2 and from laptop
>2 to laptop 1. The results were about the same.
Ok, then it probably wasn't RF interference as that tends to change in
level, intensity, effects, and such between tests.
>> 2. It would be interesting to know what IPerf reports without the
>> wireless link. Can you move one of the computers next to the other
>> and see what IPerf reports with a direct LAN connection?
>I tried that too: I connected both laptops to the LAN ports of one
>WRT54GS box, and IIRC I got about 90Mbps, or a little less.
Good. 90Mbits/sec is about wire speed for 100baseTX which requires
full duplex to get that speed. Both machines and Iperf are apparently
working correctly.
>> 3. Do your WRT54GS statistics show any wireless errors or resends?
>> It doesn't take much RF interference or reflections to drop the error
>> rate. Were the results consistant? Try it with *LESS* RF signal by
>> disconnecting both antennas on one end.
>How do I check the wireless errors and resends in my WRT54GS?
I haven't the foggiest idea. There are support groups for Sveasoft
firmware that will have better clues on using their tools. Usually,
there's some type of status page with includes MAC level errors. If
Alchemy supports SNMP, it can usually be extracted from there.
>I'll try to remove both antennas on one end and let you know if it helps.
I've noticed on the bench that there is a miniumum seperation between
radios, but have never investigated the cause. It could be overload,
timing, or my imagination. Usually about 1 or 2 meters seperation is
sufficient to eliminate any such effects. If the units were next to
each other, there *MAY* be problems.
>> 4. Are your ethernet ports on the computahs running at full duplex?
>> With 100baseTX-HDX, the best I could do with a direct connection (on a
>> Windoze 2000) machine was about 60Mbit/sec using large packets.
>
>Yes, the laptops and WRT54GS LAN ports are running 100Mbps full-duplex.
>
>> 5. Anything connected between the WRT54GS boxes that might slow
>> things down such as a 10/100 Hub?
>
>Negative, the laptops are connected directly to the WRT54GS boxes, and
>the WRT54GS boxes are connected directly with a wireless WDS bridge.
>
>> 6. Are you running any form of encryption (WEP or WPA)? Depending on
>> implimentation, this will slow you down somewhat.
>
>Negative, there is no encryption on the wireless link.
When you get it going faster, it would be interesting to know how much
WPA slows down the thruput.
>> 7. I'll confess that I don't really understand how WDS works. By
>> that, I mean how many packets are shoveled back and forth, or whether
>> there is or isn't a performance penalty for using WDS as a point to
>> point bridge. Alchemy supports a client mode. Put one radio in the
>> access point mode, the other in the client mode. Try again and see if
>> there's a difference.
>I'll try that and let you know, but I think that the WDS bridging
>feature is the recommended one for a wireless bridge by the Sveasoft people.
>I am not sure if Alchemy client mode suffers of the same limitation of
>Satori: only one computer can be wired to the WRT54GS LAN.
Well, the idea was to eliminate WDS from the performance picture. The
reason I listed it last is that it's the test that will burn the most
time. However, judgeing by the numbers offered by Neill Massello seem
to indicate that WDS does not present any overhead problems. You
should get full speed. Save the non-WDS tests for last.
One other dumb test worth trying. Just copy a large file with ftp and
time the transfer with a watch. Do the math and see what speed you
get without using Iperf.
--
Jeff Liebermann
(E-Mail Removed)
150 Felker St #D
http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558
Similar Threads
Linear Mode
