Ethernet throughput issues on armbian (at high latency)

[Mike H]

Hey fellas

 

I have FOUR different armbian devices (one official armbian, three running ophub's armbian) which all seem to struggle with network throughput at high latency connections. It is not a cpu issue and this doesn't occur on x86 debian. 

 

Here's the odd thing.

 

If I connect an ethernet usb dongle, like rtl8152b I get the full throughput even at high latency. What??? So it's a nic issue?

 

I thought maybe the onboard ethernet isn't well supported by the kernel so I got a nanopi neo4 with onboard realtek gigabit running official armbian 6.12.3x ... AND it's slow too. Any onboard nic with armbian is slow in my tests.

 

With slow I mean that a single connection gets 5-10Mbit. With a dongle I can get up to 100Mbit on a SINGLE connection from the same device.

 

Why is a usb realtek dongle better supported than onboard realtek gigabit? I don't get it. Does anybody have an idea I could try?

 

What's really difficult is that the problem only shows up at high latency. If I set up a new device at home (low latency) I get full throughput, but when it's in another country 200-300ms latency it just slows down to 5-10Mbit. The workaround with a dongle was just a fluke accident that I happen to notice. 

 

I truly believe armbian has a bright future but right now I'm tempted to go back to x86 for my needs and I'd rather not because arm SHOULD be better than x86 for IoT (my use case). 

 

Thanks for helping me figure it out. Love your work! 

[Werner]

4 hours ago, Mike H said:

three running ophub's armbian

For those we cannot and will not help. This is a fork which uses the name Armbian without permission and does not contribute to the core development process. Ask at their place for help.

 

For the leftover: armbianmonitor -u would be a good start.

[Mike H]

Hi and thanks for the reply

 

I have the device running official armbian at my location (already brought it back) and so I'm trying to figure out a way to "simulate" high latency. Any ideas?

 

Otherwise we'll have to wait a few months so I can place it at it's intended location again. As you can imagine, this is something that's taken a LONG time. Many many months and progress is slow.

Edited Tuesday at 04:58 AM by Mike H

[laibsch]

Seriously?

 

https://www.lmgt.org/?q=simulate+high+latency

https://duckduckgo.com/?q=simulate+high+latency

 

You're welcome.  "Many many months" of what?

[Mike H]

Of placing the device back with a new kernel/distro or even doing testing on it. I don't travel much and my friends who do don't have any experience nor equipment to change things.

[Mike H]

If you look at it from my point of view there's a bug in armbian. At the very least it's now been reported even if I'm not clever enough to figure it out. You aren't showing much sympathy to the regular users trying to help out by such condescending language. 

[laibsch]

Pointing out that you are not even willing to put your own words into a search engine is "condescending"?  That takes 5 seconds or less when you claim to have put months and months into it.  You are expecting others to do the work for you.  I find that quite presumptuous.

 

And no, we do not know there is a bug in Armbian.  You haven't done enough research to know enough to claim this for certain.  I will put the chances of that being the case at fity-fifty at best.  You also have presented no logs whatsoever (even after being asked) to even give others the moderate chance to do this work for you (for free).

 

If you came here to vent, OK, you have now vented.  If you came here for a solution, then sorry to say, but you are not even doing the very minimum to get that done.

[Igor]

@Mike H

 

This is a community forum, and your message is for everyone. Armbian maintainers are part of this community, but please keep in mind that support here is provided on a best‑effort basis by volunteers and maintainers who give their time when they can.

 

In open‑source projects, especially those maintained by communities, work is prioritized based on available time, skills, and resources. Sometimes an issue might be addressed quickly; other times it may take months — or it may not be addressed at all if the effort required is too great compared to the benefit. This is a normal reality in community‑driven software development. The concept of sunk cost often plays a role in deciding whether to invest effort in fixing certain issues.

 

It’s worth noting that even in large, well‑funded projects, some bugs remain unresolved for years. In our case, resources are far more limited — for example, Raspberry Pi OS has a budget exceeding €1M annually for one platform, while Armbian supports many platforms with a fraction of that funding, outside few boards we have some small maintaining budget, there is only a beer money, and far fewer people. Best-effort is the only promise that can be provided under such circumstances.

 

We appreciate bug reports, even they have nothing to do with our work as we understand users often can't judge that, but we ask that no pressure be placed on contributors to resolve them on demand. In some cases, solving an issue can take weeks or even months of work, which is not something users can reasonably expect from volunteers. And there are thousands of bugs already in the to do list.

 

Finally, please understand that part of the challenge we face is that some projects already monetize or re‑brand our work while presenting it as inexpensive and easy to maintain — when in reality, it’s not. This can create misunderstandings about the real cost and effort behind keeping a complex software stack running.

 

Your report is welcome, but we ask for patience, understanding, and respect for the time and resources of those trying to help. Pressuring volunteers to prioritize some issue, or expecting them to personally fund the work, is neither reasonable nor effective way to fix bugs.