Throtteled WAN-Upload-Speed // Bandwidth limit

[Rabux]

Hi guys, I stumbled upon an issue and I really hope someone can provide me with some insights.

TL;DR:

On my NanoPi M4 with Kernel 5.10.43 the upload bandwith is limited to about 70 % of the available bandwidth. With Kernel 4.4 it's ~95 % and with the friendlyarm-image I get the 100 % as reference.

 

Expected behaviour:

Usage of full available bandwidth

 

I'm running a core version, no desktop. No configuration has been made on all three images and the tests have been performed with:

iperf3 -p 5200 -N -t 20 -c speedtest.wtnet.de

 

Result with Kernel 5.10.x (Armbian_21.05.1_Nanopim4_buster_current_5.10.35.img): 8.03 Mbits/sec

Result with Kernel 4.4.x (Armbian_21.05.1_Nanopim4_buster_legacy_4.4.213.img): 11.0 Mbits/sec

Result with Friendlyarm-image (rk3399-sd-friendlycore-lite-focal-4.19-arm64-20210617.img): 11.6 Mbits/sec

 

LAN works fine, I get around ~960 Mbits/sec. So it must be a software issue and I have no idea why it only affects the WAN-side.

 

I discovered this issue when doing remote backups with rsync and my router only showed me partial bandwidth usage.

So I also tested with scp and finally iperf, all showing same results. Then I downloaded new images of armbian 5.10.x, 4.4.x + friendlyarm-image and did the testing to make sure no configuration from my side caused it.

 

I have a bit of a feeling this is intended behaviour not to occupy the whole bandwidth but I couldn't find any documentation whatsoever.

If you need more information let me know, I'm new to armbian so pls don't scalp me.

[lanefu]

there's a lot of variables with the internet involved.. but you could try scaling down MTU size.. or  test inside a VPN

[Igor]

6 hours ago, Rabux said:

I'm new to armbian so pls don't scalp me.

 

I hope (official) support terms https://github.com/armbian/build#support won't scare you  ... but IMO you should understand right away how things are, before asking for more. We have zero financial coverage to fix bugs in corporate business software https://www.kernel.org/. In one year we collect just enough cash to cover expenses of digging into one such bug, but sadly basic costs needs to be paid if we want to play around those things. tl;dr; Also terrible is general misperception - people that are paid to work on issues as such would take a week to dig in and remove the cause while most of users expect instant resolution and pay nothing. Sadly, we don't have a week and there are 1000 other bugs pression on way too small team of people that have interest to fix things in common good. There are just a few people that maintains this complicated system.