ePMP 4525 - Single vs Multi TCP Streams

Is it to be expected for TCP performance to be lower and more erratic for a single TCP stream vs multiple TCP streams?

Here is a chart showing the difference on a 4525 SM connected to a 4500L AP in WLR mode. I am doing a Mikrotik bandwidth test through the SM to our core Mikrotik router.

Modulation rates were a steady MCS 11 on the SM and all Downlink and Uplink traffic were sent via MCS 11 according to the SM Stats. No other traffic was running on the SM as this is a test environment.

I have also noticed more oddities with TCP and low stream counts in a duplex test. See photo below where 1, 2, and 3 TCP stream tests gave very weird results.

In case anyone is wondering here is the wireless stats for this SM after the tests.

Single directional tests in Uplink seem ok no matter how many streams, but Downlink has issues with single stream and duplex with less than 5 streams.

To give a reference of the link performance here is the link test to this SM.

Link Test

1 Like

I did find that on low TCP stream counts I more often got what I would call normal results if I enabled Random Data on the Mikrotik bandwidth test tool. Per the manual Random Data does the following.

If random-data is set to yes, the payload of the bandwidth test packets will have incompressible random data stream so that links that use data compression will not distort the results (this is CPU intensive and random-data should be set to no for low speed CPUs.

So with Random Data disabled I get the results above but with Random Data enabled I would usually get more normal results. And by normal I mean that the send/receive are more even, but single stream TCP is still lower overall bandwidth with more variation vs higher stream counts. Does this mean there might be an issue with how the 4525 or 4500L handles compression of the data when using low TCP stream counts?

Hi @terintamel,
please PM me tech support files from AP and SM. Need it to understand your observations.

Actually I did open a ticket on this and recently sent the tech those files. The ticket ID is 353878 if you want to get involved in that.

Sure! Thank you!
I see it is 5.4.1-RC10. Pretty fresh RC but we will publish a new one soon.

May we know what settings did you use, Terintamel ? Which Mikrotik devices were used on both sides, what signal level and SNR on wireless side ?

170Mbps you achieved is too little for 20MHz/1024QAM, at that config it easily should have been ~220Mbps TCP. Single TCP stream or multiple should NOT play any role because this throughput is very low so it’s easily achievable.

Of course distance plays role, interference too but your throughput seems to be very stable.
Give us details, please.

SM side is ePMP 4525 connected to a Mikrotik hAP AC2. AP is a ePMP 4500L connected to a Ubiquiti Edgeswitch S16. S16 is connected via 10G fiber to a CCR-1009. Test is run between hAP AC2 and CCR-1009.

SM is configured as NAT router mode. AP is bridge. Distance between SM and AP is around 436 ft. This is an outdoor test setup with only on SM on the AP.

SM Downlink and Uplink MCS is over 99% at 1025-QAM 5/6.

Settings I am using on Mtik bandwidth test is TCP. I test both in send, receive, or both (duplex) mode. I test with both Random Data enabled and disabled.

brilliant, thanks a lot ! I know AC2s, actually I use two as wifi routers at home. They are not the most powerful devices, but sure manage 200Mbps with ease.
Looking at your detailed info, I only would suggest to turn off NAT on SM plus decrease TX Power on both radios. -43dBm might be too strong, overloading wireless parts : decreasing by 6dB should still comfortably keep you at MCS11 modulations, you should have something like -49 / -51dBm then.
I know it sounds strange and of course I can’t claim this will help.

Force 400 at 9km (6 miles) link, 40MHz : https://forum.nag.ru/uploads/monthly_2021_11/42502.png.301f763b31f0e79d21cb9cefc041ec84.png

40MHz, real ISP, real traffic, no artificial tests, mixed udp, tcp, big, small packets : https://forum.nag.ru/uploads/monthly_2021_01/1109251093_Force425450Mbps.jpg.4cb6ae4da2180fc304849a044fd9c2f6.jpg

20MHz provides 240-250Mbps. Pictures are not mine.

I will try the TX power suggestion.

I am not really concerned with the overall performance as I do expect that running the SM in NAT mode will impact total bandwidth ability. My concern and reason for the thread was the irregularities I saw in how the system appears to handle high vs low TCP connection counts along with some possible major duplex issues.

My current network is Ubiquiti and all CPEs are in Router mode with NAT. Since I am evaluating ePMP 4500 series as a possible upgrade and replacement for my AirmaxAC equipment I need to test them in as much of a like for like configuration as possible. Testing in Bridge mode might give me more bandwidth and might not show this issue. It could be just a NAT mode problem.

very valid and responsible thinking.

The biggest advantage of epmp4500 ax platform will be their interference resiliency, resistance and rejection. There aren’t enough re* words to describe how those radios cut through noise :slight_smile: my jaw dropped when I saw it. I believe the reason is 2MHz SU - or even smaller, I don’t know - of Cambium “PHY” protocol : instead of one big 20 or 40 or 80MHz “chunk”, you have multiple independent small carriers. If some of them are affected by interference, only that part of data is lost and has to be retransmitted instead of “complete train”.

Quite usually, my friends report 350-400Mbps throughput where previous radios (regardless of manufacturer and model) were so-so doing 100Mbps, with much better latencies, jitter etc. On the same channel, the same TX power, the same antennas (just replace radios and their power, that’s it, don’t touch antennas at all). Moreover, UBNT products are not exactly interference-champions either.
NAT can be done on different place than SMs. Should you lose 15-30% of potential performance due to NAT performed at SM devices, it might be better to NAT on real router somewhere down the line in your network… I would not give up that much wireless performance.

Please keep us posted about the result after decreasing TX Power. Simple, easy, fast, free, wouldn’t hurt.

1 Like

Lowering TX power at SM or AP to get the signal in the 50s made no difference to performance or to the low vs high TCP connection count performance.

This was expected, I just tried. Thank you very much for your effort and confirmation !
There are occasions where too much signal is really too much. Well, Cambium has quality products.

I changed the SM to Bridge mode and ran the same tests and got the same results. NAT mode is not hindering my SM performance.

1 Like

FYI for anyone following this. I have been going back and forth with Cambium support on this and the latest response to me was this is expected behavior of the WLR mode.

I am not sure what to think about that as the other equipment I can test this with use a TDD protocol (LTU).

In fact this test link replaced an LTU test link. All I did was put the 4500L on the same antenna the Rocket LTU was on and then put the 4525 SM on the same pole on our roof as the LTU Pro SM was located.

I may swap them back to LTU and run the same tests, but it will not be a truly fair comparisson as the LTU is Fixed-frame and TDD while the 4500L is basically enhanced standard 802.11ax Wifi.

I am not saying the LTU is a better product, just that for this specific test the LTU does not exhibit the same oddities as I found with the ePMP. Once the 4500 gets TDD (as of now maybe 1 year from being out of beta) then I expect it to be much different.

However until then I will probably continue to hold off any live customer deployments until TDD, Fixed-frame and GPS sync are working and available in this product. I am not sure I trust WLR mode yet.

1 Like

I will also mention I tried this setup in ePTP mode and while I got more bandwidth overall the low TCP could oddities were still present. I guess ePTP mode is not TDD either?

Basically anything under 4 TCP streams would have consistently inconsistent performance when doing duplex testing. Single direction testing would work perfectly fine at any stream count.

1 Like