Archived from groups: alt.internet.wireless (More info?)

Hi,
I setup a WDS bridge between two WRT54GS wireless routers running
Alchemy 6.0rc4a, I have a laptop connected (wired) to the LAN 1 port of
the first WRT and another one connected to the LAN 1 port of the other WRT.

I put the WRTs pretty close: according to the wireless status page, they
are running a full 54 Mbps link with a RSSI of about -35 dBm.

I ran some bandwidth tests for the wireless bridge using the 'iperf'
utility:
<http://dast.nlanr.net/Projects/Iperf/>

I only got about 12 Mbps, I tried both ways: from laptop 1 to laptop 2
and viceversa, the results are about the same.

I think I should get a lot more bandwidth (about the double, e.g. 24
Mbps) out of a full 54 Mbps link.

Any idea?

What are your results?

Thanks a lot.

Archived from groups: alt.internet.wireless (More info?)

If I read your mesage right, you have 2 wrt54gs with a wds (repeater)
in the middle. In this case your throughput is about right because a
repeater cuts the bandwidth by about 50% because it has to receive then
re-transmit every packet. So 54bps has an actual data throughput of
about 22 to 24mbs or so then cut that in half and your in the ballpark.

Archived from groups: alt.internet.wireless (More info?)

On 12/28/04 8:44 PM, Airhead wrote:
> If I read your mesage right, you have 2 wrt54gs with a wds (repeater)
> in the middle. In this case your throughput is about right because a
> repeater cuts the bandwidth by about 50% because it has to receive then
> re-transmit every packet. So 54bps has an actual data throughput of
> about 22 to 24mbs or so then cut that in half and your in the ballpark.

Actually I don't have any wireless repeater in the middle, I just have
two WRT54GS wireless routers setup in LAN WDS bridging mode.

No other wireless equipment, the laptops are connected (wired) to the
LAN ports of the WRT54GS boxes.

Any idea?

Thanks.

Archived from groups: alt.internet.wireless (More info?)

On Tue, 28 Dec 2004 12:26:49 +0100, meATprivacyDOTnet <me@privacy.net>
wrote:

>I setup a WDS bridge between two WRT54GS wireless routers running
>Alchemy 6.0rc4a, I have a laptop connected (wired) to the LAN 1 port of
>the first WRT and another one connected to the LAN 1 port of the other WRT.
>
>I put the WRTs pretty close: according to the wireless status page, they
>are running a full 54 Mbps link with a RSSI of about -35 dBm.
>
>I ran some bandwidth tests for the wireless bridge using the 'iperf'
>utility:
><http://dast.nlanr.net/Projects/Iperf/>
>
>I only got about 12 Mbps, I tried both ways: from laptop 1 to laptop 2
>and viceversa, the results are about the same.
>
>I think I should get a lot more bandwidth (about the double, e.g. 24
>Mbps) out of a full 54 Mbps link.

The problem here is that you plugged everything together and found
that it didn't quite work. The trick is to find which *PART* of the
problem isn't working as expected. Some things to try:

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)?

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?

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.

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.

5. Anything connected between the WRT54GS boxes that might slow
things down such as a 10/100 Hub?

6. Are you running any form of encryption (WEP or WPA)? Depending on
implimentation, this will slow you down somewhat.

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.


--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558

Archived from groups: alt.internet.wireless (More info?)

Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:

> 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.

FWIW, a not-very-scientific data point follows.

Using a Buffalo WBR2-G54 (AP/router) and a WLA-G54 (AP) linked by WDS
(client access enabled on the router, but no active wireless clients at
the time of the test) with a good strong 802.11g signal and S/N ratio, I
moved more than 3GB from the WLA-G54 to the WBR2-G54 at a fairly steady
rate of 24 to 25Mbps. (I couldn't really measure the wireless transfer
rate, so that figure represents what was going out from the sending
computer via Ethernet.)

I can't give you comparable figures for a client connected to either of
the Buffalo boxes, because I don't actually have any 802.11g client
devices.

Archived from groups: alt.internet.wireless (More info?)

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.

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.

I don't have the iperf output handy now, but it was about 12Mbps. 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.

> 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.

> 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'll try to remove both antennas on one end and let you know if it helps.

> 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.

> 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.

Thanks.

Archived from groups: alt.internet.wireless (More info?)

On 12/29/04 7:52 PM, Neill Massello wrote:

> Using a Buffalo WBR2-G54 (AP/router) and a WLA-G54 (AP) linked by WDS
> (client access enabled on the router, but no active wireless clients at
> the time of the test) with a good strong 802.11g signal and S/N ratio, I
> moved more than 3GB from the WLA-G54 to the WBR2-G54 at a fairly steady
> rate of 24 to 25Mbps. (I couldn't really measure the wireless transfer
> rate, so that figure represents what was going out from the sending
> computer via Ethernet.)

24 to 25Mbps, that's a good throughput, that's what I would expect from
my WRT54GS boxes too ...

Did you use any special option for your WDS bridge?

Thanks.

Archived from groups: alt.internet.wireless (More info?)

On Thu, 30 Dec 2004 11:06:56 +0100, meATprivacyDOTnet <me@privacy.net>
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 jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558

Archived from groups: alt.internet.wireless (More info?)

meATprivacyDOTnet <me@privacy.net> wrote:

> Did you use any special option for your WDS bridge?

Frame bursting is enabled, and the bridge unit is doing WDS exclusively
("dedicated mode" in Buffalospeak). Nothing else special, but I should
also have mentioned that the WDS link uses 128-bit WEP.

Archived from groups: alt.internet.wireless (More info?)

On 12/31/04 2:58 AM, Neill Massello wrote:

> Frame bursting is enabled, and the bridge unit is doing WDS exclusively
> ("dedicated mode" in Buffalospeak). Nothing else special, but I should
> also have mentioned that the WDS link uses 128-bit WEP.

I already enabled the frame bursting option on my WRT54GS boxes, it
didn't make any noticeable difference ...

I couldn't find any WDS 'dedicated mode' in the Sveasoft firmware.

What radio chipset do you APs use?

Thanks.

Archived from groups: alt.internet.wireless (More info?)

On 12/30/04 4:33 PM, Jeff Liebermann wrote:

> 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'll try it asap and let you know.

> 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.

You are right. The problem is that I don't have the LinkSys WRT54GS
boxes next to me, there are in another location, I cannot do other tests
until this week-end.

> 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.

Okay, I am going to do some 'googling' for that.

> 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.

There separation between the WRT54GS boxes is about 2 meters and the
RSSI is about -35 dBm (overload shouldn't be an issue).

I am going to try more separation and/or to remove the antennas from one
AP, just to be sure.

> When you get it going faster, it would be interesting to know how much
> WPA slows down the thruput.

Yes, I plan to turn on WPA as soon as I get a good bandwidth without
encryption. I'll let you know how it affects the throughput.

> 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.

Agreed, I'll save the AP/Client test 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.

I already tried a similar test: I got about 1.5MBytes/sec trasferring a
file via SMB/CIFS (Windows sharing). That is about the same throughput
reported by the iperf utility: 12Mbits/sec.

Thanks.

Archived from groups: alt.internet.wireless (More info?)

meATprivacyDOTnet <me@privacy.net> wrote:

> What radio chipset do you APs use?

I'm pretty sure Buffalo uses Broadcom in most of their wireless
products.

Archived from groups: alt.internet.wireless (More info?)

On 12/31/04 5:58 PM, Neill Massello wrote:

> I'm pretty sure Buffalo uses Broadcom in most of their wireless
> products.

That's interesting, since the WRT54GS wireless router also a Broadcome
chipset. In theory I should get the same (or similar) throughput of your
WDS bridge ...

Archived from groups: alt.internet.wireless (More info?)

On 12/31/04 10:19 AM, meATprivacyDOTnet wrote:
> On 12/30/04 4:33 PM, Jeff Liebermann wrote:
>
>> 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'll try it asap and let you know.

I tried a bigger window size (about 200K, since it didn't accept 500k),
it didn't make any noticeable difference from the default setting.

Here is the iperf output from the MTU discovery test:
---
[ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet)
---

>> 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.
>
>
> Okay, I am going to do some 'googling' for that.

I couln't find any instructions on how to read the WRT54GS statistics
yet. Anyone?

>> 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.
>
>
> There separation between the WRT54GS boxes is about 2 meters and the
> RSSI is about -35 dBm (overload shouldn't be an issue).
>
> I am going to try more separation and/or to remove the antennas from one
> AP, just to be sure.

I loaded the latest Sveasoft firmware: Alchemy 6.0rc5a.

I increased the separation between the WRT54GS boxes to 10 meters or so:
the RSSI is now about -60 dBm, the wireless link is still running at
54Mbps, the average throughput increased a little bit (e.g. 13Mbps).

I also got 17Mbps for a couple of iperf tests, but I wasn't able to
reproduce them.

I am not sure if the small average improvement is due to the bigger
separation between the wireless boxes or to the new firmware version.

>> 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.
>
>
> Agreed, I'll save the AP/Client test for last.

I tried to setup the wireless brige with a WRT54GS box in AP mode and
the other one in client mode, but it didn't work for some reason: when I
clicked the 'Survey' button in the 'Wireless Status' page of each
WRT54GS box, it couldn't see the other one.

I am going to more tests as soon as I get a chance, but my guess is that
I won't get much more additional bandwidth from my equipment ...

Thanks.