Weird perfomance!

[prozak]

Hello.

I want to share a weird issue in my topology.

I’m providing internet access to a remote location through a mountain node.

Current topology with IDs for later explanation.

(1)RBHEX(ISP 200Mbps Down / 20 Up ) —>(2)DynaDish5<—>(3)LHG-XL-AC<—(4)CRS125---->(5)LHG-XL-AC<—(6)DynaDish5---->(7)RB3011(remote location)

Problem is, i cannot seem to get full potential speed of 200Mbits(downstream) to my remote site.
So the weird performance goes like:

BT TCP Metrics
From (1) to (3) = ~133Mbps Rx ~180Tx
From (2) to (3) = ~133Mbps Rx ~180Mbps Tx (Just as expected, stable transmission) – 802.11Protocol
From (1) to (5) = ~250Mbps Rx?? , ~110Mbps Tx??

While

From (5) to (6) = ~110Mbps Rx, ~125Mbps Tx (Stable transmission but, can and will be improved in the near future) Nv2 Protocol
From (5) to (7) = ~110Mbps Rx, ~125Mbps Tx (as expected as well)
From (7) to (3) = 220Mbps Rx, ~140 Mbps Tx ???
From (1) to (6) = ~50Mbps Rx , ~75Mbps Tx
And finally
From (7) to (1)= ~74Mbps Rx , 44Mbps Tx

I know BT test between different equipment power is unreliable, but what are those weird metrics?
I’ve also set in an OrangePi2E iperf server on my internet site(1) and run through remote site(7) on my pc and results are the same.

Is this some sort of TCP window size ive been reading? Tested with 1 and 20 TCP streams and I still get identical metrics,

Links (2) to (3) and (5) to (6) are simple bridges.
My CRS125 on the mountain node, was previously set with software vlan method, which I changed it with the switch menu method.
I also read in the forum and changed interface queue types to ethernet-default, but still the same results.
Is the CRS to blame? Am I missing something else here?

I would appreciate some help because im breaking my head..

[mutluit]

For CRS3xx the docs say that currently HW Offloading is effective only on one bridge.
Not sure whether this applies to your CRS model(s) as well, so check the docs.

[prozak]

bump

[bpwl]

bump

What is your problem? The 250/ 220 or the 50/44 ??? Or both?

For the 50/44 wifi details are needed. Channels used, A-MSDU, A-MPDU, protocol used, …

[prozak]

The problem is the speed at endpoints from (7) to (1) is = ~74Mbps Rx , 44Mbps Tx.
As i descibed in the original post the concept is to achieve as much as possible. I got confusing metrics between endpoints that make no sense.
Isnt that enough?
Protocol between 1st link devices (2) and (3) is 802.11 while (5) and (6) is nv2 ( tried also 802.11).
AMDPU on both links is default at 0 only.

[bpwl]

The problem is the speed at endpoints from (7) to (1) is = ~74Mbps Rx , 44Mbps Tx.
As i descibed in the original post the concept is to achieve as much as possible. I got confusing metrics between endpoints that make no sense.
Isnt that enough?
Protocol between 1st link devices (2) and (3) is 802.11 while (5) and (6) is nv2 ( tried also 802.11).
AMDPU on both links is default at 0 only.

No not enough, no. You don’t give the channels used. 802.11 and NV2 cannot cooperate, they use a different mechanism to decide on media access. They will interfere badly if the channels overlap or are too close together. The RF beam is not only at the front of the antenna, so the LHG-LX-AC can seriously disturb each other, even outdoors if pointing in opposite direction.

Without giving those details asked for , you are on your own.

[prozak]

No offense but I think you havent clearly understood the real issue here.
Links are directed to different direction and different altitude (on a 40m Tower).
First link is as i said 802.11 and second is nv2. The connective nodes at the tower are both LHG XL AC and connected to a CRS in a simple bridge.
Does those wifi protocols interfere in a way when they come into CRS?
The nature of the problem is, the unsual speed metrics from point to point that doesnt make sense.
Testing from remote site (7) to the first node in line LHGXL (5),i get lower speeds than testing from remote site(7) to the node that goes beyond CRS, LHG XL AC(3).
I mean its not a device cpu power issue. im testing the same type of equipment.

[bpwl]

No offense but I think you havent clearly understood the real issue here.
Links are directed to different direction and different altitude (on a 40m Tower).
First link is as i said 802.11 and second is nv2. The connective nodes at the tower are both LHG XL AC and connected to a CRS in a simple bridge.
Does those wifi protocols interfere in a way when they come into CRS?
The nature of the problem is, the unsual speed metrics from point to point that doesnt make sense.
Testing from remote site (7) to the first node in line LHGXL (5),i get lower speeds than testing from remote site(7) to the node that goes beyond CRS, LHG XL AC(3).
I mean its not a device cpu power issue. im testing the same type of equipment.

I 'll rest my case. Final answer here.

Yes the two LHG LX AC on the tower in opposite direction and at different altitude can interfere at the RF wifi signal sent/received. How much are the side lobes of the signal spectrum reduced? 25 dB? Still plenty of power to interfere. This happens only when both LHG’s are active in your measurement. So that speed will be half or even much less if freq/channels are not separated far enough.

The other one is weird indeed. But you mention BT test. If it is run on a Mikrotik that has to do the wifi processing as well as the data sending/receiving, then watch for CPU and interrupt bottlenecks on that device!
In the 7-3 test, the data comes in over ethernet, not over wifi in that BT device, as is the wifi case for the 7-5 or 5-7 test. Test details lacking.
BT tests should never be done with source or destination on the device that is challenged.

[prozak]

It turns out Interference was indeed the issue. Run 2 simultaneous tests between 2 links and when the 2nd kicked off i saw the performance drop on the 1st.