4

I have a simple L2 network consisting of two chained wireless PtP links. 

[LOC A] -------> [LOC B] -------> [LOC C]

         .4ms             .7ms

Here is a list of the PtP bandwidths:

A -> B 300Mbps

B -> A 300Mbps

B -> C 300Mbps

C -> B 300Mbps

However, when we test the network (using iperf, 10 parallel threads) from A -> C, we see the following:

A -> C 130Mbps

C -> A 130Mbps

Link from A -> B is a microwave link operating at 23GHz

Link from B -> C is a 5GHz PtP radio.

When we test the links individually, they look OK, passing 300Mbps as they should be. However, when we test the network end-to-end, from A -> C, we never see more than 50% of the bandwidth we expect, and usually see closer to 33%.

None of these links are passing customer traffic.

Is this network congestion? Could it be caused by the two links operating with different latencies? Would this difference in latency cause buffers to fill up on one of the radios?

Thanks!

Improve this question
4
  • Are those latencies round trip? A 1.1ms round trip wont interfere with a standard TCP window of 64KB but a 2.2ms rtt will start to cut into it just a bit (here is a calculator to help: switch.ch/network/tools/tcp_throughput/…). – Jeff Meden Jun 2 '15 at 20:38
  • Yes, these latencies are round trip. Im curious if the difference in latency would cause an issue. Seems almost like packets are arriving quickly to the first radio, but becoming congested in the second link. – Ethan H. Jun 2 '15 at 20:42
  • Have you tried tweaking the TCP window that Iperf is using? If the rate goes up and down with the window size, that might tell you if its a timing issue or if there is some other overarching bandwidth limitation. – Jeff Meden Jun 3 '15 at 12:41
  • Are the links running on non-overlapping radio channels? – Peter Green Apr 12 '18 at 3:51
1

Different latencies are no problem but they do add up.

When multiple, parallel flows behave the same as fewer flows this rules out general latency/TCP windowing problems. The BDP of 82,500 bytes indicates an LFN though, TCP requires tweaking with few flows.

My bet is on channel interference. Each link by itself performs fine but both in conjunction don't. Both channels' bands are different and shouldn't interact but they still might.

Check

  • Do both HF channels/antenna cables have enough distance between them? Don't run them in parallel for more than absolutely necessary.
  • Is there a frequency conversion for the 23 GHz channel between antenna and radio? (This I really suspect as 23 GHz is hard on the cable.) The converted frequency might relate to the 5 GHz link.
  • Run throughput tests for each link on both links simultaneously - I'm guessing one of the links performs poorly while the other fills up to 300 Mbit/s. If so, the poorly performing link experiences interference from the other link.
  • If the radio logs can be accessed (might need turning on and setting to detail) check for radar detection events and such. These would indicate interference between the channels/cables.
Improve this answer
0

No. Different latencies are not the problem here. Nor are window sizes since you are using 10 parallel connections. TCP handles different latencies and bandwidths all of the time. My guess is a layer 2 duplex mismatch problem - one radio is forced to full duplex and the the other is set to auto.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.