With latest snapshot or even latest release, wifi tops out at ~300 mbps as does wired from lan->wan. I ran top and CPU is not even close to being maxed out when I do a speedtest, so doesn't seem like a lack of hardware forwarding as the issue if I analyzed correctly. Where is the bottle neck here?
I put the stock firmware back on and then I see 620mbps wifi, and 920mbps wired. (1 gbps cable modem)
Could there be any mis-configuration on my part? Please help I want openwrt firmware back.
My understanding is with OpenWrt 18.06 or Master builds, kernel 4.14 has flow offloading enabled and you should have no problem reaching 900Mbits. It won't be quite as fast as OEM firmware because of proprietary hardware NAT but it should be close.
I'm running a vanilla master build with software flow offloading, and I noticed that the CPU wasn't running at its fastest frequency while benchmarking WAN<->LAN. Speeds consistently topped out at 600Mbps on a gigabit link.
Enabling software flow offloading in firewall config: helped with fq_codel/simple, but not with cake/piece_of_cake
Tweaking ondemand governor settings as suggested by @ddwrt_refugee helped with both cake/piece_of_cake and fq_codel/simple, with or without flow offloading. With both governor tweaks and SW flow offloading, I got line speeds with fq_codel/simple.
Hardware+software flow offloading made no difference vs. software-only. Can't tell if R7800 hardware is supported?
Has anybody tracked down, where the original values come from ? It is likely in Linux kernel, but have the values been tweaked for specific processors? Or just for a generic architecture family?
If the original values have been drafted for basic calculation tasks, it might well be that sporadic irq driven network traffic needs different values like discussed above.
EDIT:
Based on a brief look at the kernel docs, it might be that the default 95% originates from the Linux kernel itself and no CPU-family specific tailoring has been made.
This defines what the average CPU usage between the samplings of
'sampling_rate' needs to be for the kernel to make a decision on
whether it should increase the frequency. For example when it is set
to its default value of '95' it means that between the checking
intervals the CPU needs to be on average more than 95% in use to then
decide that the CPU frequency needs to be increased.
Might quite well be that the default for Openwrt should be changed, as the IRQ driven load by network traffic may not generate constant 95% load.
35% sounds maybe a bit low, though.
EDIT2:
Looks like the default values are hard-coded to Linux. no config options:
One other thing is the division of IRQs on CPU cores. By default all IRQs get assigned to core0, so the load is not split evenly. You might look into R7800 IRQ discussion in R7800 exploration thread, and e.g. to irqbalance
(also manually doing IRQ splitting to cores is possible.)
(also manually doing IRQ splitting to cores is possible.)
I found pinning eth0 / eth1 on their respective CPUs to be a crucial step. It gave me better performance in bufferbloat tests, opposed to running irqbalance without any configuration.
However, I had issues with irqbalance in the past (like 8 - 10 months ago), leading to spontaneous device reboots. Was running it on my NBG6817 though, not on my R7800. Did anyone else run into it here?
This setting does not help with my WAN - LAN speeds. I'm only getting 300mbps maximum with the latest version of hymnan. Any other solution? Thanks
Furthermore in earlier versions of hymnan the setting Tweaked settings for ondemand scheduler worked but after a while the device freezed and rebooted:
echo 35 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
Have you turn on Flow Offloading in Firewall page? I recently set up my R7800 by resetting all the settings, change only the Flow Offloading and the 2 line u mentioned.
with no SQM
My own Lan test peak at 700Mbps at dslreports
Comcast's XMT device Lan test reach 960Mbps
Thanks again for your hint but somehow after a lot of traffic load (Steam Downloads) and a lot of connections the R7800 crashed and restarted twice. I had the same issue after altering the up_trhreshold and sampling_down_factor after a while (2-3 days). Without altering this settings i never had the issue I will try to reproduce the issue and gather some logs.
single stream is always around 400-450 for me
using dslreport speed test can reach more than 700 at least
i also got crash, i just updated his latest no ct ver of firmware, i think using the old non ct should be the fix for crashing (i am not entirely sure but seems yes)
It uses ct by default, but it's really easy to switch with 'make menuconfig'. I wonder why is it being an issue for you? I use yesterday's master with ath10k firmware driver and everything is rock solid and the speeds on 802.11ac are 850 mbit/s on average.
not sure but it seems like enri experienced the same issue. What is your line speed? Maybe this is related to a higher bandwidth / more traffic on WAN?
Do you know how i can trace some log files when the error occurs?
With gigabit speeds, you should likely forget about CPU frequency scaling "ondemand", and simply set the "performance" scaling governor.
Your crashes may be due to something going wrong with the scaling.
In general, there not been reports of R7800 crashing, so your case(s) seem rather unique, so far.
And you should try to separate the wifi part vs. generic router fixed line part. ath10k-ct or old ath10k have impact just on wifi. The interesting part si, if the crashes are due to the base system or the wifi firmware/driver.
Thanks for your attention. But as a beginner i don't know how to troubleshoot this / gather logs. After the device crashes i have to turn it off and after the next start the systemlogs are gone... How do you do it to save logs?
Furthermore i did a complete factory reset and installed master-r8410-900005ee75-20181104-c. I'm using Adblock, DDNS, Dual Stack (ipv4 and ipv6) with software flow offloading enabled but without changing the ondemand scheduler. I will try to reproduce the crash today.