After upgrading from 5.4 everything worked without any configuration changes.
However, the download speed does not go over 860 Mbit/s, and top shows 100% usage on one cpu.
On TOS 5.4, I was able to reach about 930 Mbit/s and both cpus were at about 50%.
I am using an SFP GPON adapter to connect to the internet, in case that matters.
Is there something I have to change in the configuration or is this a known issue?
I would say that many are quietly envious of you 
The router is also running sentinel analytics and dynamic firewall and whatever else you have installed - these require some performance overhead that limit speeds a bit. At these high transfer rates, you’re also hitting a CPU limit. In general - the maximum is theoretical for most of the parameters quoted - and not just for Omnia.
By the way, you didn’t specify what download you were testing – the limit may also be the device on the other side and the load on the line. The result may vary as you test during the day or night.
I’d look at htop and see what’s consuming your stress power there.
My idle CPU load also increased with version 6
===
EDIT: if this is really a TOS problem, it could be solved in the future when version 6.x.x is stabilized
The router is also running sentinel analytics and dynamic firewall and whatever else you have installed
I don’t have these enabled nor any other cpu intensive features that I can remember.
By the way, you didn’t specify what download you were testing –…
It was the web version of speedtest.net from my computer, that accesses the internet through the router.
Just to make sure, I rolled back to a snapshot with 5.4 and had my original speed. After restoring 6, the issue reappeared.
I’d look at
htopand see what’s consuming your stress power there.
Just like top, htop only shows increased cpu usage, but nothing that uses it.
I think the problem here is that only 1 cpu is used.
Even in Speedtest the test server is selected - manually the same or automatically … the results will be different. Wait with the problem when the version is stabilized - the load of only one core is interesting information. Try searching this forum to see how similar problems were solved in older versions of TOS.
I see in htop exactly the processes sorted by CPU power requirements
Testing with Speedtest net etc is not accurate, it varies according to load of the servers in between. If you test from wifi also not also not accurate, wifi has never 100%, at max can 93%.
You should test directly from the router, so try iperf for testing, but it is not easy for internet. Some public iperf servers can give better results.
I have no idea how did someone
I can not find the link at the moment, but I recall reading that the Turris Team is still working to get some kernel patches accepted and some that were accepted are not available with OpenWRT 21.02, on which TOS 6.0 is based. You might search for DSA (distributed switch architecture), and see that it was a goal for OpenWRT 21.02.
If you’re daring, you might test with the HBL release branch (bleeding edge) for very early TOS 7.0 testing, which is based on OpenWrt 22.03.
Like others said, Speedtest is unreliable for these kinds of tests - especially at high speeds.
That said, here’s a test using it from a box I have that’s connected over Cat6 to the router:
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by WorldStream B.V. (Naaldwijk) [308.01 km]: 16.784 ms
Testing download speed................................................................................
Download: 721.59 Mbit/s
Testing upload speed......................................................................................................
Upload: 479.89 Mbit/s
Here’s an iperf3 test from the same box:
$ iperf3 -c iperf.par2.as49434.net -p 9213
Connecting to host iperf.par2.as49434.net, port 9213
[ 5] local 2a01:4b00:9d42:96ff::9 port 59192 connected to 2a0f:9240:1018::2 port 9213
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 106 MBytes 890 Mbits/sec 11 1.00 MBytes
[ 5] 1.00-2.00 sec 71.2 MBytes 598 Mbits/sec 5 583 KBytes
[ 5] 2.00-3.00 sec 73.8 MBytes 619 Mbits/sec 0 671 KBytes
[ 5] 3.00-4.00 sec 85.0 MBytes 713 Mbits/sec 0 763 KBytes
[ 5] 4.00-5.00 sec 96.2 MBytes 807 Mbits/sec 0 852 KBytes
[ 5] 5.00-6.00 sec 105 MBytes 881 Mbits/sec 0 943 KBytes
[ 5] 6.00-7.00 sec 95.0 MBytes 797 Mbits/sec 4 743 KBytes
[ 5] 7.00-8.00 sec 93.8 MBytes 786 Mbits/sec 0 826 KBytes
[ 5] 8.00-9.00 sec 102 MBytes 860 Mbits/sec 0 916 KBytes
[ 5] 9.00-10.00 sec 102 MBytes 860 Mbits/sec 4 708 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 931 MBytes 781 Mbits/sec 24 sender
[ 5] 0.00-10.01 sec 929 MBytes 779 Mbits/sec receiver
iperf Done.
And here’s iperf3 to the same server, directly from the router:
turris# iperf3 -c iperf.par2.as49434.net -p 9213
Connecting to host iperf.par2.as49434.net, port 9213
[ 5] local 2a01:4b00:9d42:96ff::1 port 46706 connected to 2a0f:9240:1018::2 port 9213
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 109 MBytes 912 Mbits/sec 0 1.27 MBytes
[ 5] 1.00-2.00 sec 110 MBytes 923 Mbits/sec 3 1.06 MBytes
[ 5] 2.00-3.00 sec 110 MBytes 923 Mbits/sec 0 1.17 MBytes
[ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec 0 1.27 MBytes
[ 5] 4.00-5.00 sec 110 MBytes 923 Mbits/sec 3 971 KBytes
[ 5] 5.00-6.00 sec 110 MBytes 922 Mbits/sec 0 1.03 MBytes
[ 5] 6.00-7.00 sec 110 MBytes 923 Mbits/sec 0 1.09 MBytes
[ 5] 7.00-8.00 sec 110 MBytes 923 Mbits/sec 0 1.14 MBytes
[ 5] 8.00-9.00 sec 110 MBytes 923 Mbits/sec 0 1.21 MBytes
[ 5] 9.00-10.00 sec 110 MBytes 923 Mbits/sec 0 1.27 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.07 GBytes 923 Mbits/sec 6 sender
[ 5] 0.00-10.01 sec 1.07 GBytes 920 Mbits/sec receiver
iperf Done.
There is a (consumer 
) switch between that box and the router though, which might be the culprit for the slowdown - although I see a similar ~930Mbps for iperf between router and box. I will test from another box connected directly to the router later but if I see similar results, the slower speeds are likely the result of routing or some other operation on the router.
Most of the overhead in top for that test is on sirq which goes from near 0% to around 50%.
The browser version of Speedtest works well enough for me. Previously, I almost always got something around 930 and now it’s always around 860.
If one CPU is at 100%, I don’t think the speed can go any higher without some additional change:
Indeed, when running iperf3 from the router to a server on the internet the speeds were higher:
I found a comment by @Pepe that seems to be related, but it’s not really that clear:
