Belkin RT3200/Linksys E8450 WiFi AX discussion

I had no trouble rebooting with 300000, 437500 or 600000. Noticed reduced power usage from 5.8W idle down to 5.5W @ 437500 and 600000. Interestingly the 300000 option consumed 5.6W...

echo 300000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo "ondemand" > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor

Edit: second time I tried 437500 my power meter dropped to 5.6W so seems like the three options save about the same amount of power.

The 300000 is possibly wrongly interpreted or not accepted at all, unless you have first patched kernel sources, as the OPP point is wrongly defined there. DTSI defines 30000 instead of 300000 (although 300000 was the intended value for that OPP point).

See https://github.com/openwrt/openwrt/pull/4440#issuecomment-897884454
and
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/mediatek/mt7622.dtsi?id=a5a80f78657f7d7b9b73bc67d0a18d5997c91168
(note the difference of 0s in the OPP title and the given value... :frowning: )

+		opp-300000000 {
+			opp-hz = /bits/ 64 <30000000>;

Visible here:

root@router4:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
30000 437500 600000 812500 1025000 1137500 1262500 1350000

At least I get 437500 as the lowest current frequency with ondemand:

root@router4:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq
437500

Regarding voltages:

Note that the 1,31 V is defined in the upstream Linux kernel for the 1.35 GHz opp point:

+		opp-1350000000 {
+			opp-hz = /bits/ 64 <1350000000>;
+			opp-microvolt = <1310000>;

Hi, hw offloading has no traffic speed effect, instead seems to add 10% to the CPU usage... Also the test is not using ipv6.

1 Like

Thanks for the explanation :slight_smile: appreciate it. Since it's obviously a known mistake, why hasn't it been fixed?

Assuming layer_cake.qos/cake in sqm, both qosify and sqm end up instantiating one or two cake instances, after tey are done they get out of the way and the run time cost only depends on the configuration of those cake instances.... and on the fact that qosify will also have some efficient ebpf code running that implements the dscp setting rules. So qosify might take a bit more CPU, but just if it does more, once you use e.g. iptables to perform classification and dscp remapping for sqm I expect qosify to be less CPU-hungry again.

Yes, and that's correct. My statement of 1.0V was wrong, I just remebered it wrongly (and actually only MHz was mentioned).

Could you fix the 30000/300000 discrepancy in our local DTS, at least for E8450?

(That should be fixed also upstream, but that might take long. I sent mail to the original mediatek author when I noticed the discrepancy in August, but he newer answered)

I am aware that having a packet priority processing mechanism will consume CPU, but I was wondering why it cannot consume more than 60-65% CPU and thus have a better speed. It seems that there is a limiting process somewhere and I do not know if it is due to the configuration or implementation of the algorithm.

1 Like

For me hw-offloading reduced cpu-load a little while transfers. Disable ipv6 just as there is a bug with enable hw-offloading. But i have ancient german internet access i dont need it.

I had some weeks also a load-bug. It was one of the dyndns packages which caused it. I removed it and just put a "wget" call into onlinechanged hotplug directory. It had a huge impact:

@hnyman I know that all devices run with 1,31, even when @daniel say 1,0 is "official"
For the 30mhz fix see my link to PR above

@Jip-Hop I have not so a good power meter, so i watched temperature of the device. It is about 5 °C higher in 1,3ghz only mode

1 Like

I misquoted that as I already corrected in Belkin RT3200/Linksys E8450 WiFi AX discussion - #1196 by daniel

One MediaTek employee stated that the SoC is only supposed to be run at maximum speed. Other MediaTek employees submitted a DTS including lower operating points. Choose what's more official for you.

I imagine that orientation of the device would be a decent factor in the cooling of the device here, due to the direction of the fins on the heat sink. It's obviously intended to stand the router up and let convection do it's thing.

How are people's temperatures when running in this manner?

As a worst case scenario, with similarly speced hardware running in horizontal, with an objectively worse finless heat sink, in 30 degree ambient...

~# cat /sys/devices/virtual/thermal/thermal_zone0/temp
58200

With ondemand with the 300mhz min_freq, it brings it down a glorious 2 degrees :slight_smile:

Ah, thx! I did not see it, that @hackpascal edited the post, removed the max-1V statement and writes now only-1,3ghz -.-
But seriously, a cpu does care about mhz, as long as it is not more than max.
If you want more than max, you need some more voltage, which could burn the cpu because of to much heat

@elan Im telling this since 6 months!!1 Btw, 10 °C less means 2x life time
https://forums.sandisk.com/t/technology-life-testing/31085 -> 14day is like 104 years, when the default temp of 40°C is rised to 125° (2^8,5 faster aging)

2 Likes

I was quite impressed to take mine apart and see the large heat sink. CPU chip temperature only 30 C above room temperature is real good for a fanless system.

1 Like

As I understand, the bug is when doing ipv6 NAT. I don't have ipv6 NAT, just DHCPv6 with prefix delegation. Maybe I'm wrong but I think the hw-offloading for NAT is working only for the ethernet ports and currently Felix and others are working for the ethernet - wlan offloading (only for "download"). I think I'll do some tests with ethernet connection to see if there is a visible difference.

Its multiple times in the posts above

Is consensus from everyone that lower normal temperature despite thermal cycling on load will result in greater longevity? How much are we talking? From what to what?

I don't think he has edited anything, probably I just remembered it wrongly (and didn't check because the point was mostly that cpufreq on MT7622 is not officially supported while on the other hand it was other MTK devs submitting mt7622.dtsi which includes the lower OPPs, but at least one of them obviously wrong...)

Coming back with results of ethernet client tests. Unfortunately I only have a slim laptop with USB3-Ethernet adapter and this seems limited to ~ 700Mbps, however I noticed some similarities:

  • hw offloading actually increase the CPU usage with approx 10% (vs sw offloading).
  • qosify limits download to max 500Mbps, but not the upload and adds roughly 10% CPU usage.
  • in all tests CPU is mostly under 30% even without sw offloading.
  • in ideal conditions (sw offloading, no qosify), CPU is under 10% most of the time.

So, as a router, the CPU is not an issue for 1Gbps internet connections. The problem is with ethernet - WLAN processing that is taking a huge load on the CPU. Let's hope we'll have soon good results from the mt76/wed work :ok_hand:

4 Likes

Hi, I have purchased my third Linksys E8450, and am going to set it up soon. Any reason to await a new release of the installer, or should I just go ahead with 0.6.1? I'll update it with auc later anyway I guess, but if there are any updates to uboot or the firmware worth waiting for, I might leave it in the box for a few weeks.

Today I took the risk and compiled + tested the "wed" branch from Felix's staging tree. Very good results: hw offloading does make now a big difference -> 850Mbps download using the Wifi client with 30% CPU! And this is with qosify active, which seems it doesn't limit the download speed anymore! For upload there is not much difference to the normal openwrt/master version but we know that offloading is only for the Ethernet to WLAN path. Cannot tell much about stability, yet, but I have not noticed any strange events yet.
Congratulations to Felix, Daniel and all others who contributed to make this router a beast!

3 Likes