ZeroPi running at max CPU speed with collectd

Been running OpenWrt without much issues on a little Zeropi board. Saw a new (for me) collectd cpu frequency package and after installing noticed my cpu always runs at max speed.

When I manually set the governor to ondemand my wireless speed goes from 50mb/s to 5mb/s. It is near instant too. Setting it back to performance and the speeds go up right away.

I use OpenWrt in client mode to bridge a network and did the same on the same board with Debian and iptables/wpa_supplicant before and cpu scaling worked ok there. It was set to ondemand by default and ran at 600mhz most of the time. As that setup isn't ideal when it comes to managing it and no nice web interface too I wanted to move it to OpenWrt.

OpenWrt defaults to performance and runs at max freq all the time. It is also running a bit hotter, no surprise. I tried experimenting with nohwcrypt=0/1 but no difference. Since it works ok in Debian with the same kernel version (5.y) I would hope it can also work in OpenWrt. I don't like the idea of the cpu being forced at max speed all the time.

Is there any way to fix this or does OpenWrt require the cpu to run at max speed?

I've tried this in 19.x and the rc and the current version, they all behave the same.

1 Like

I sold my orange pi zero and R1 a couple of years ago and bought 2 bananapi M1's instead.

It's a tiny 40x40mm FriendlyElec one, should've clarified with all the pi zero's and zero pi's out there :grinning:

1 Like

I noticed that OpenWRT on a ZeroPi doesn't like varying cpu freqs (what the ondemand governor does).

Just select the performance governor, but limit the max cpu freq. I'm running at 816 MHz. Alternatively: select powersave governor and raise the min cpu freq to a higher value. Just try and error to find out the best freq value in both cases.

Thanks for the insight. I guess the OpenWrt team is also aware of this issue, which is why it defaults to performance mode. They must have weighted the options and decided that running the cpu at max clock speeds was the best solution.

I wonder what in OpenWrt makes it "not like" the normal cpu scaling cuz it works perfectly fine in normal Linux/Debian. Even with a governor like conservative there are no drops in wireless speed. Thanks again. I'll do some experimenting with your suggestions.

I'm not sure "OpenWrt team is aware of this issue", nor that they care much. OpenWrt developers focus on maintaining and developing the generic parts of the firmware, not the specific hardware configuration for each device.

Hardware support is added (and maintained) by community contributors and the reviewer may not know enough about the device to do more than a basic sanity check (i.e. it seems good and does not break OpenWrt).
This is the commit where the contributor added your device https://github.com/openwrt/openwrt/commit/679db02b10474e8a685baeecc37ddd511f1d4808

I have a suspicion that by "linux debian" you actually mean Armbian. That's not "normal linux debian", they carry kernel patches and enable/disable options to make it work on the supported devices. The kernel they use may be configured or patched differently than the kernel of OpenWrt on your device.
For example these are the patches they add on top of debian kernel https://github.com/armbian/build/tree/master/patch/kernel/station-current

Even Debian and OpenWrt kernels may be configured differently. This is the kernel config of OpenWrt https://github.com/openwrt/openwrt/blob/ec6293febc244d187e71a6e54f44920be679cde4/target/linux/sunxi/config-5.4

1 Like

That's indeed a really good question, but I haven't an answer. Maybe @bobafetthotmail's posting is a reasonable explanation.

Thank for the great insight!

I've ran several Debian based distro's, including Debian's own ARM builds for this arch. The manufacture also provides OpenWrt images but they're a bit outdated but I will try them and see if cpu scaling works properly there. If they fixed it shouldn't be too difficult for me to apply those changes to the OpenWrt build tree. I've build OpenWrt with custom modules/kernel patches from source before.

Armbian is indeed most polished and stable on ARM devices they support. I assumed OpenWrt devs would be aware of those and apply them on the supported devices too but as you explained they only provide the basics and the rest is up to us.

Maybe it should be made more clear on the wiki pages for supported devices that OpenWrt builds for it are not optimal and more like a proof of concept. I wish I was aware before hand the cpu would be running at max frequency all the time. Not that it would break my h/w but it sure ain't good to force cpu's to always run at their max frequency.

Since I'm not a programmer I can do not much more than try my luck with patches/fixes from other places, post here and hope one day configurations/fixes/patches/etc from other places are applied to the supported devices in proper way (unlike me haha). But I know that might never happen since the list of supported devices is quite large. Maybe the threshold to call something supported could be higher? I don't consider my Zeropi supported anymore knowing what I know now. This probably applies to other supported devices too.

For me the solution right now is to either live with it, force the cpu to run at lower speed or setup OpenWrt in a (lxc) container on top of one of the Debian based distro's. The latter seems the best way to go. All the power management and cpu scaling will be handled by the host OS and OpenWrt runs on of top of that doing all the fancy things I want it to do.

the CPU was designed to run stable indefinitely at that frequency, as long as temperature is lower than a max level that is usually above 90 celsius.

The CPU governors that lower CPU frequency exist mostly to save power, and not overheat the CPU for no reason if the cooling is inadequate (like for example in a smartphone, they all can get very hot and shut down).
The CPU will still termal-throttle (reduce its frequency) or shut down if overheated. Thermal protections are integrated.

Actually using governors can make the device less responsive because switching frequency is not istantaneous and there is some time that the device is still running at low frequency before it realizes that yes it needs to go faster now.

Some people just set it to "performance" governor aka max frequency either on PCs or servers or small devices that are not connected to a battery. The only downside is higher power consumption, and that you need a better heatsink.

Since these are low-power parts and it is not a smartphone you can probably just attach a small passive heatsink on the chip and it will be perfectly fine.
(there are heatsink kits for the raspberry Pi for example and you can reuse that or find similar cheaper parts).

All devices in the same target for sure, as they share the same kernel, so all devices with the same brand of CPU have the same problem in OpenWrt.

this may or may not work depending on what features you need. A lot of routing and firewall features of OpenWrt (for example the SQM) require the OpenWrt kernel or will try to install OpenWrt kernel modules that probably won't load on a Debian kernel.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.