Optimising the Omnia for gigabit wired throughput

i have a Gigabit connection and want to fully utilize it. I did notice strange behaivior with the Omnia. The throughput is waving, it fluctuates between gigabit and 500 mbit/s. I tested with a factory reset (3.x.x) a updated 3.x.x and with the HBK branch, they show all the same behaivior. If i plug my PC directly in the modem i get stable 940 mbit/s out of it.
Here some screenshots to visualize (take a look at the blue line of the download)
directly connected to the modem

with the omnia in place

Is this “normal” because of hardware limitations or can i do something to fix it?

If you need more informations just write what you need and i will add it.

Thanks for help

Check the TO’s CPU utilisation during such test (e.g. with htop), whether an app is particularly spiking the CPU usage.

If so suspend such app, unless being something elementary to connectivity, and see if the result improves.

that is the highest utilization i saw at a 900 mbit peak

So it doesn’t seem like the CPU is maxed out?

is it the peak CPU utilisation from the entire test period?

Pretty much, here a video of a speedtest https://imgur.com/yCYHo5Q

In that video it spikes to almost 80% with top userland consumers:

  • rcpd calling mwan status
  • foris controller (strangely)

are multiple WAN interfaces present (mwan)? If not you may want to suspend mwan and test again.

You could also alternate the htop visualisation, e.g. hide userland and show kernel threads

other bandwidth suits yielding the same jittery graph, e.g.https://speed.cloudflare.com?

yes there is a second wan connection, but that is only used if the main one dies complete and it is reproducable with the omnia even with the factory image and everything at default.

Video with other htop settings Imgur: The magic of the Internet

Sure, it just adds significant CPU utilisation.

Curious that foris controller is spiking the CPU usage significantly. Do you have Foris UI open in a browser during the test? Though it is likely not the cause but for the purpose of elimination could you suspend the process and test again?

I did not have Foris UI open. And did now factory reset the omnia to elimate anything that could cause problems. The spikes from Foris UI are gone now, but the fluctuation is still there.

directly attached to the modem

It might be down to kernel performance then

In short, it would take some effort to analyse in depth, e.g.

  • start with a custom kernel build, preferably from mainline source and compare performance
  • turn kernel knobs and compare performance

Here is some thread Can't get 1Gbit on Mox Classic, albeit about the M it touches some aspects of the intricacies of the kernel’s network stack and traffic control management tuning and patches in OpenWrt related to network performance.

I have the problems with TOS3.x too like i wrote

The much older kernel in TOS3.x is not likely to outperform the kernel that ships with TOS5.x

You could give HBD (probably best as vanilla medkit) a spin as it features a more contemporary kernel and see whether is yields better results. If neither that or tuning some kernel knobs (sysctl) or some input from this forum provide satisfactory results you could always engage the manufacturer’s diagnostic routine https://docs.turris.cz/basics/support/.

I have 4.0.5 and htop is about 30-50% on both cores during test. Somethimes foris notify comes up too, but that also without running test. Here is my speed graph:

is a bit more flat and the ditch is actually when he is switching packages size and only happens in Firefox, in Chrome it is like that:

It may helps you if you have compare values. With 3.x.x btw. i never realized a “waving” speedtest.net had everytime a flat graph.

PS: at speedtest.net is the load 90% on one core and 40% on second…but still fast

ah, just reallized…you mentioned wired speed…i have SFP directly integrated in Omnia…

btw: Performance degradation with pakon or device discovery

That doesn’t help, i did factory reset and did not install any additional software and it still happens. Sadly i can’t test via SFP, because there is no DOCSIS3.1 hardware with it.
But i would be very interested in sysctl tuning that @anon82920800 mentioned so if somebody has a suggestion what to try, i would be very thankful.
I do reach the 940 mbit/s but like you could see it will go down short after reaching them and then recover, so it is not a hard cap. Looks a littlebit as some kind of congestion control does kick in on the omnia or maybe windows? which does not happen if I’m directly connected to my modem.

There might be a difference between the copper (WAN) and SFP port related to the Marvell 88E1514 Gigabit Ethernet transceiver insofar as the copper port might be subjected to transceiver’s

  • flow control over CAT5 UTP cable

whilst SFP is not.

a search in the public domain turns up some links for such knob settings

1 Like

what is the output of ethtool -a eth2?

root@turris:~# ethtool -a eth2
Pause parameters for eth2:
Autonegotiate:  on
RX:             off
TX:             off
RX negotiated:  off
TX negotiated:  off

Could not find anything that explains what that feature does and whether it only applies to CAT5 UTP or other cable types as well. Just thought that in case your TO is connected to the modem via CAT5 UTP to give it a shot with a different cable type like CAT 7 | 7a | 8.1.