I have a strange problem. Doing bandwidth tests from router a to router b gets about 40Mbps tcp one way. Doing tests from router b to router c gets about 40Mbps tcp one way as well. Doing tests from router a to router c gets about 25mbps tcp one way. So it goes on. The further the tests, ie, from router a to router d,e , the less throughput I get.
The links between the routers are Rocket M5’s in a transparent bridge configuration. The routers are RB750’s. I am doing the test from a Routerboard 1100.
Has anyone had the same problem? Is it a problem or a limitation? Any help or advise will be appreciated.
BTW tried with Airmax on/off. Configured MPLS as well. Still same results.
TCP throughput is affected by packet drop and latency unlike UDP throughput. Measuring from a point beyond each router is usually the best approach for accuracy but the TCP process needs to be understood and considered when interpreting results.
I see the same problem and blaming it on tcp/ip seems very bogus. So, if we have:
RouterA<-(wireless UBNT 40Mbps)->RouterB(wireless MT 40Mbps, bridged RB433GLs,nstreme, dual polarity-N, 40MHz)->RouterC and all routers are not overly loaded (CPU<20%)
we “should” see 40Mbps between RouterA and RouterC. If we don’t, (and we don’t) there’s something wrong–it’s not TCP/IP overhead.
OSPF routing, v6.2 on RB450G(A), RB493AH(B) and v5.5 on RB1000(C).
Ever since I went to Gigabit connections and RB433GL’s as the radios at one of our sites things have not been working well as far as throughput.
My comment was simply highlighting that UDP and TCP tests will generally produce different results because of the differences in the protocols. e.g. - the overall latency does affect TCP throughput but not UDP throughput. I looked at one system which had lower than expected TCP throughput. The data supplied by the customer all looked good but they had only measured the latency on the radio link when at idle. In fact the latency on the radio link as spiking under load and the additional latency was affecting the measured TCP throughput. Solution? Buy new (more expensive) radios…
Pinning down these problems even with full access to the gear takes some effort and understanding. It is even harder when only a few of the facts are available on an online forum like this which is why we end up with some frustrated posts. Additionally, some specific equipment/protocols/interconnections/combinations may indeed have specific operational problems which can be hard to pin down unless the problem can be demonstrated in an isolated manner.
