Slow transparent bridging

Hi all, I’ve finally got an headache!
I’ve recently set up a wireless link that connects two sites across two intermediate POPs: the network setting looks like this:
SiteA ← link A → POP1 ← link B → POP2 ← link C -->SiteB.
All devices in the network are the same: RB411AH with R52Hn installed in outdoor case that integrates dual polarization 23dBi patch antennas.
Whatever the specific link settings (802.11a or 802.11n, single or double chain, nv2 or nstream, …, bridge-stationwds or bridge-stationbridge, combine what you want…) I’ve got this common strange bahaviour: bandwidth test between hosts in site A and hosts in site B results in a throughput significantly less than that available testing directly from RB411AH in site A and RB411AH in site B.
Some results; configuring all links to get the maximum (802.11n@20MHz, dual chain, nv2,..) I’ve got a bridge-to-bridge test of an almost flat 50MBps in TCP (connection count 20) and 80Mbps in UDP. The host-to-host test in same confitions drops to a 9Mbps.
Trying with all link in 802.11a@20MHz, single chain, nstream (with no fragmentation) I’ve got a bridge-to-bridge test of 20Mbps TCP and about 30Mbps UDP. The same host-to-host test leads to 9Mbps, just like in 802.11n.
Introducing nstream fragmentation (best-fit 896 bytes) host-to-host results increase from 9Mbps to 12Mbps. Why?
These results induced me to investigate on local ethernet connection between wireless bridge and local lan on site A and B. I’ve tested Cat5e ethernet cables with Fluke tester. All tests passed correctly on both sites.
On the ethernet side I’ve tried two solutions:

  1. directly connecting testing PCs to the wireless bridge ethernet ports, excluding all swithing devices;
  2. passing through switches (3Com4500 on one side and HP2510 on the other)
    In both case ethernet links negotiates 100Mbps full duplex with no physical errors. host-to-bridge bandwidth test on both sites results in 80Mbps TCP.
    I don’t know what to try and what to do next. Any ideas? Does MT bridging work correctly? Why results with nstream fragmentation are better than those without?
    Any idea is really appreciated.
    Have a nice day.

The host-to-host test in same conditions drops to a 9Mbps.

With what do you test from host to host (program)? I am guessing it is two PC’s, what operating system do they have?

Hi, I’ve testes using three differente methods, all with the same results: mikrotik bandwidth test for PC, clientsend/hostrec and by FTP file transfer.
Both PC are Windows XP SP3. Before running my test session I’ve tried a test between two PCs directly connected. Almost 100Mbps both side.
I forgot to say that all wireless bridges are running ROS 5.4 and that the host-to-bridge tests in both ways (PC in Site A → bridge in Site B or PC in site B → bridge in Site A) gave me the same result obtained in host-to-host test. The only way to get the maximum is between whatever pairs of bridges.
I’t not the first time I occured in this behaviour… my sensation (but I have no proofs…) is that this has something to do with the correct matching on frames size between wired and wireless interface. In fact I had a moderate improovment on performance while changing from nstream with no fragmentation to nstream with best-fit @ 896 bytes.
Thanks for your interest.

Was asking about PC because i know some of the newer Windows have limitations on amount of connections and so forth. As far as i know, Xp good though. If your MTU for Wlan and Ether is both 1500 there should not be fragmentation problems.

Find the reason, non solution!
The reason: the reason for slow performances is in TCP Window Size; hosts exchanging test data can’t “fill” the link bandwidth. Using iperf with a TCP windows size of 800kbytes (instead of default 64kbytes) I had an huge increment of performance (more than 50Mbps tested with onboard bandwidt test).
The solution: given that it’s impossible to tweak TCP parameters on each host is there a way to get out of this problem?
Thanks in advance to all.
f.

You can adjust the metric on XP under the advanced section of TCP/IP properties. Windows XP can be fairly dumb when it comes to auto-adjusting the window size, set it manually to 1500 and try again.