Actual throughput is lower than link test shows (force 300 + AP3000)

Hello. On sector ePMP3000 with smart antenna FW 4.5.5 23-24 clients online, sector working in 80Mhz channel, Downlink Max Rate is DS MCS 6. Average usage less than 60 Mps.

!!! Results with Link test !!!

!!! Results with Btest from customer mikrotik router made to mikrotik which connected to the same switch with AP. !!!

Customer have subscription 80 Mbps… Other customers who have less distance and better results with SNR can take full subscription speed.

Question: why is there such a big difference in results and how can this be corrected?

Ps All cables have been checked, no packet loss, etc.

Couple of suspicions -

  1. Why do you have your DL MCS limited to 6? Was 9 causing less tput or lots of fluctuations due to retries?
  2. 80MHz means you are using a very wide channel so probably getting a lot of interference. Can you share a screen capture of your spectrum analyzer?
  1. Unfortunately, no one canceled the interference, as well as the noise. Using high modulations leads to retransmission of packets, which negatively affects the quality of service. The first to suffer are the gamers. We are on an island and the best ping to the mainland is 70 MS. The combination of 80 MHz and MCS 6 gives us better results than any other combination.

Any way, my question is - why Link test results not actual?

If you think about link test, its like UDP traffic in that it doesn’t care about lost packets, re-transmissions, backoffs etc. More than likely your TCP results are off because of interference. I can say that with confidence actually. If you look at your spectrum the noise floor is in -60 so look at your RSSI and you know what your C/I is. If you want to up your tput, we need to try and get the C/I higher. What are you using on your SM side? Since this is a specific scenario on an island, do you have the luxury of using horn antennas, connectorized products and just get your gain up higher and use the horns to fight off some of the interference?

1 Like

Hello Alex,

in addition, use 40 MHz as channel bandwidth in the meantime and use the frequency range shown by blue lines:

.

Sincerely yours,

Niragira O.

Dear Ahmed
On this sector we have a mix 300-19 with 300-25. Exactly for this customer we use 300-25. I have in stock 300 connectorized radio, but with 30dbi dish it’s to high cost for ordinary customer connection.
We already use full radio power from sector side, but with sector antenna 120 degree (MuMIMO). About retransmits, plz look at picture from cnMaestro:

!!! Customer side !!!

!!! Sector side !!!

As you can see - on download retransmits is low, so i cant find good excuses why it’s happens.
The sector is very optimistic about the state of the subscriber’s connection and the SNR is not bad at all.
image
Of course, with a high level of SNR, we will have better results, but for what reason did cambium make uninformative diagnostic tools and a quality meter???

Dear Olympe
It’s impossible to use this RF according local law.

You did the test by CAMBIUM with large packages, by default the BTEST is different, did you notice that? , I have done comparative tests and the closest thing to the real thing in CAMBIUM test is MEDIUM 800 bytes for 10 seconds

Same results like with big packets size…

morning test with 100 connections
image

in evening time results significantly worse, but link test shows any time unreal high results

Hello Alex,
do you have GigEthernet ports on your switch/routers/laptop at the tower where you have the AP or testing site?

Sincerely yours,

Niragira Olympe

Thanks for your helping ))) On this pillar I have fiber interconnection with core, 1G/10G ports on switch, and other sectors and ptp links…
for example this is ptp to one customer with 200mbit subscription

!!! port on switch !!!

So I have not any infrastructure issues. And i have full monitoring including errors/drops on ports with notifications. Everything tested and under control.

Hello Alex,

that is good to hear. Try to reduce the channel width for some time just to assess again your link. You can use 40 MHz channel width and see.

Sincerely yours,

Niragira Olympe

How does the CPU of that MIKROTIK behave at the time of the test? Is the connection interface of the MIKROTIK with the SWITCH at 100 or 1000? the switch what model is it? (It would be good to know the equipment models at the origin of the test and the destination) MIKROTIK switches are not good with the tests

Hello Alex;
Here is some 80Mhz results I had using a Force300 - this picture is test using the bandwidth test between two MikroTik routers… so this isn’t using the internal Cambium tests at all. I know this isn’t helpful in diagnosing your issue, but wanted to show that the F300’s can carry a lot of data.

/original/2X/e/e1fada86e8556ff9f546b455a213b6ca0acc4fb3.jpeg

1 Like

This is totally a 80mhz channel issue. Occurs on 4.6.x and on the latest 4.7 betas. From my experiencing, the throughput on the link test is what you should get. IMO, the throughput is there, however the way TCP traffic is handled with interference is broken.

300-80mhz-linktest
300-80mhz-udp

Despite the fact that in theory an 80mhz channel should have a good performance gain, I had to completely abandon this idea. The performance using the 40MHz channel exceeds the performance of the 80MHz channel, and also shows significantly better resistance to interference.

It is really like this because you need a very wide channel to be clear. I see it possible not very frequently. Especially with long distance links and in congested areas

That doesn’t explain how UDP gets good performance close to if not equal to the link test. Drop to 40mhz channel and the difference is that the link test correlates with UDP and TCP bandwidth tests.

To add to that, I have fairly long ptp links (8-15km) on 80mhz channel with equal TCP and UDP speed over the links. Standard TDD not PTP TDD or ePTP. When there is interference, the link test shows the performance drop as expected, but with a solid link test, there shouldn’t be any issues with TCP speeds IMO.