Contents of /proc/cpuinfo vary between architectures, mips and arm never displayed the CPU frequency - and just for the avoidance of doubt, the bogomips value is indeed bogus. If you want to know the current frequency, check cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq.
I noticed /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq and /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_cur_freq doest't go hand in hand always..
You're probably catching it while it's switching frequencies and you're not reading the 2 values in any atomic way and there's perhaps some delay for these values to get updated on the virtual fs. One value is what the governor wants the freq to transition to and the other is what it actually is.
FWIW, I run mine with performance governor always at 1.7GHz so I don't have to think about these questions
I think about it the other way: why not use the perf governor all the time, what is the harm? In my experience it adds about a 2C temperature increase which is just noise really and some will say it uses more power, but then again just noise in the grand scheme of things of how much power you use in a household (there may be use cases where low power use is a requirement but those I don't think are common).
In the past there were issues with ondemand switching frequencies at low freq but I think those are fixed now. That's why you'd see people recommend using 800MHz as the lowest freq with ondemand.
I experimented with ondemand, schedutil and performance governor and chose to always use performance for ... max performance.
This is for people building for R7800 by themselves:
Looks like commit fa731838 in master causes trouble for R7800.
PC does not get DHCP address via fixed line. But wifi works ok and PC gets IP.
But nothing obvious seems to be amiss.
Router seems to boot ok, ifconfig shows sensible stuff at the first glance, all settings were restored & etc.
I reverted that for my master-r16678-cde31976e3-20210507 build, which made R7800 to work again.
A bit of a rant, but still. Made a build using current 21.02 branch and ath10k-ct-htt, no SQM and other bells-and-whistles.
Default performance of both NAT and WiFi is just horrible, one CPU core at 100% another is sitting idle. I had to manually:
install and enable irqbalance
enable packet steering
enable NAT software offload
ramp up ondemand governor settings.
Only then NAT performance could barely cap my 500Mbit/s ISP link.
WiFi reaches around 550-600Mbit/sec of TCP iperf3 on 867 PHY rate.
I mean its 2021, IRQ issues on multi-core Openwrt platforms have been known for years, as well as (partial) solutions to them. Why, oh why can't these mitigations be enabled by default to reach majority of OpenWrt users and give them at least average performace, instead of horrible one?
Even then, without SQM R7800 should run circles and NAT gigabit line without breaking a sweat, at 50% load or so.
Little MIPS CPU on TPLink WDR4300 could software fastpath NAT at 700Mbit/s in OpenWRT years and years ago, where is a bottleneck now?
Eagerly awaiting your patches, quick, I'm holding my breath.
--
The performance limits and pecularities about ipq806x vs NSS/ NPU offloading are well documented by now, please search for them.
Furthermore, don't compare apples to kiwis - hardware performance and out-of-tree offloading are not a fair comparison. Without SFE, the tl-wdr4300 barely achieves 150 MBit/s, while ipq8065 does 500 MBit/s, at its limits, but still.
