Powering up/down any circuit always isn't as nice as just keeping it running, as power-on and power-off moments stress all the power regulating components the most. That being said, you may kill the device if you keep powering it off and on every minute for some hours/days/weeks. From a device maker like Belkin/Linksys I would expect that they stress-test their designs to make sure they can stand at least a few thousand power-up/power-down cycles, so doing that once a day is within the expected usage pattern for this hardware and should be fine for some years.
Hard to tell, but in general sqm/traffic shapers are tough on powersaving, since they often are not throughput, but latency limited, but at low frequencies CPU latency is often bad, but traffic shaping will not necessarily generate enough CPU load in itself to make a scaling governor like ondemand operate the CPU at a high enough frequency.
I would guess though that potential detrimental effects are SoC specific and should be easy enough to test for.
Interesting. All my boards reboot at 437.5MHz@1.0V without any problems. But as said, it can totally be that this depends on various random factors (different batch of RAM chips maybe, for example) as officially the chip should run 1350MHz@1.0V only.
The best would be to fix this in TF-A and have bl2 reset the registers in charge of cpu frequency and voltage to their defaults before initiating the (proprietary) DDR RAM calibration which hangs otherwise...
Mine RT3200 also reboots fine with 437500 and ondemand. It worked fine with schedutil without setting the min freq.
What about poweroff
, did you test it? My router doesn't want to stay off and starts again in a minute or so.
Seems like testing desirable to ensure this longevity hack doesn't break SQM. Dumb question time but doesn't temperature cycling up and down like a yo-yo and associated cyclical expansion and contraction itself give rise to more wear?
My e8450 runs and reboots perfect since months! 96% of time @300. i fixed 300, add 125 and am using 1V as minumum. Ondemand-gov enabled and minimum mhz to 300 set. If not min300 is set, there are very many transitions. I can not find differences between 125 & 300 min in temperature and watt. Patchs are in an closed old pr
It's not implemented, I guess, because a simple halt of the CPU won't do because the watchdog is then out for us and reboots the system as we are not maintaining it. Maybe we can tell the watchdog to go to sleep as well on poweroff to support that simple case?
A fully featured implementation for poweroff
incl. timed wake-up or even Wake-on-LAN would probably need something like little kernel (lk
) in MediaTek-speak, ie. an alternative OS loaded for low-power mode...
boot was never a problem, even 125mhz 0,9v. but REBOOT does not work if such a low mode was used during reboot as uboot does not reset voltage properly which is needed for more mhz
It would have to be ARM Trusted Firmware bl2
to do that, somewhere around here
Yes, but the voltage, gov and min frequency changes run good
officially the chip should run 1350MHz@1.0V only.
Wow, why does openwrt runt it (without changes) constant by 1,31V?
Every mhz step 0,5V is added, thats why 125mhz could be 0,9v
Is 1,35ghz now the official value? Sometimes they wrote 1,30.
See https://forum.banana-pi.org/t/banana-pi-bpi-r64-mainline-openwrt-image/11415/313?u=dangowrt and make the best out of it
The best of a person i dont know, has 6 posts, and tells someone tells and does not link the source?
Well...
What should hapen if a process runs on low mhz? You need much time.
What happe if you have to low voltage for selected mhz? It crashes and reboots (maybe filesys errors)
To much voltage, eg 1,31V with openwrt instead (as someone told me) the official max of 1,0V?
All devices with openwrt will burns - except mine, which runs 96% of time at 1V
ADDITION: running with 5-10 °C more reduces the expected live time of the device
@fda wouah you pnumer of packages is impressionnant
can you share if you can the build with your package for example with samba etc
on the site please
https://asu.aparcar.org/?version=SNAPSHOT&target=mediatek%2Fmt7622&id=linksys_e8450-ubi
i really appreciate
thanks for all and happy new year everyone
i'm hope the stable version of future version in OpenWrt in this router soon
Sorry, i cant do this. My images have many patches and dont work for other people as expected, simples thing is a changed static ip after factory reset. And i changed many thinks i just dont like but i know they will never get megred, eg shorter menu labels.
If you build you kernel by yourself you could use these patches for the frequency+voltage https://github.com/openwrt/openwrt/pull/4440
no worries I was not talking specifically about modifying the voltage shortcut etc but more unbound samba etc that I would need in the future too bad thank you anyway
Yesterday I compiled a new firmware with qosify
instead of sqm
. I just edited the bandwidth inside the config. The results are not so good for the download speed: max 480Mbps with 63% CPU. The upload speed seems unaffected (but the CPU is busier): 650Mbps with 82% CPU.
As it seems the CPU is still not fully loaded when downloading, is this some configuration issue that limits the speed?
Also noticed that sw offloading has no effect when qosify
is activated.
To try to speedup
- disable ipv6
- enable hw-offloading
@[Dopam-IT_1987: Really much things has small changes
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... )
+ 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>;