DietPi high power usage vs Debian

Troubleshooting
1

Creating a bug report/issue

Required Information

  • DietPi version | latest 8.20 with all patches applied
  • Distro version | bookworm
  • Kernel version | Linux 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-2 (2023-07-27) x86_64 GNU/Linux
  • Architecture | amd64
  • SBC model | Native PC (x86_64)
  • Power supply used | picoPSU 160W
  • SD card used | NVMe SSD

Steps to reproduce

  1. Run latest DietPi on a x64 machine, measure power usage
  2. Run latest Debian on a x64 machine, measure power usage

Expected behaviour

  • DietPi should have lower power usage than Debian - this is literally THE lightweight OS

Actual behaviour

  • Power usage of a basically clean (outside of some configuration) install of DietPi:
    • 25-30W from the wall
    • s-tui reports 4.7-4.8W CPU package power
  • Power usage of latest Debian 12 standard:
    • 15-20W from the wall
    • s-tui reports 2.7-2.8W CPU package power

Extra details

This is not exactly an issue report, but I don’t understand why this is happening. I got a good deal on a Ryzen 3 2200G + motherboard combo, and I want to upgrade my “home server” (currently RPi 4) to it. DietPi was the obvious choice, as I also used it on the Pi, but the high power usage of a clean install shocked me. I downloaded and booted up Debian live to compare, and its out-of-the-box power usage is like 60-70% of DietPi! Quite a significant difference!
So I went on researching how Linux works with CPUs. Scaling drivers, scaling governors, kernel modules… I was expecting to find DietPi using some suboptimal driver or whatever. But no, I compared as many things as I could between Debian and DietPi, and they seem to be all the same!

Thus, I don’t understand how there’s this radical power usage difference. Can anyone try to shed some light on this? Shouldn’t DietPi be even more lightweight Debian with some extra tooling and optimized configs? How come it uses more power?

2

for testing, could you keep both images running for 2 hours and check following afterwards

cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor

as well, check power consumption after 2 hours. DietPi is executing a couple of maintenance task right after boot.

3

DietPi

3500000 160
2300000 0
1600000 728144

schedutil

Debian

3500000 542
2300000 41
1600000 740098

schedutil

This looks to be in favor of DietPi. I don’t understand…
The power consumption after 2 hours is the same as in the OP.

4

hmm strange. @MichaIng any ideas

5

Very strange indeed. With the CPU being >99% in idle, the little differences do not really matter, it should show the same power usage most of the time. Not sure how s-tui obtains the CPU package power exactly, but of course here as well: Same frequency should result in same power. There is no way to have the voltage-frequency mapping changing with CPU governors. Only the CPU scheduling driver, or even only the kernel (?) should be able to have an effect on this. Just to be sure:

  • The kernel is exactly the same on both system, isn’t it? uname -a
  • Can you check in lsmod whether the same CPU scheduling driver is loaded in both cases? Since we do not touch this, it should be the same as long as the kernel is the same, but lets assure that.

If we ignore the s-tui reported CPU package power for now, of course other hardware elements could cause the overall increased power usage:

  • Is this a headless system or do you have some monitor attached, or are you even booting into a desktop where the GPU could be further used compared to console mode?
  • If you have a monitor attached, even if just in console, is the resolution the same?
  • Do you use Ethernet or WiFi?
  • Do you have any other peripherals attached and could detach those temporarily to check whether it makes a difference?
  • And the NVMe SSD is the only attached drive? It should be impossible that it along makes such a difference, but you could check its power state as well: hdparm -C /dev/nvme0n0p1 and whether it supports APM: hdparm -B /dev/nvme0n0p1.
6

The kernel is indeed the same - 6.1.0-10. The second uname version (not sure what precisely that represents) is only one patch different (6.1.38-2 (2023-07-27) on DietPi vs. 6.1.38-1 (2023-07-14) on Debian live). Unless something went very wrong in that patch, I don’t think that’s the difference, because…
…I also now tried Linux Mint live. With Cinnamon, so fully graphical. The power usage is very similar to Debian live, it only rises when I move the cursor around. It has kernel 5.15.0-56… (from what I read, there’s a lot of AMD Ryzen optimizations in 6.0 and 6.1, so 5.15 should be much worse - well, nope)

  • So yeah, I do have a monitor attached, but that’s not the problem
  • Ethernet only
  • As for peripherals:
    • The NVMe drive (which hdparm can’t query unfortunately (all I get is unknown when asking for power state and nothing when asking for APM support - maybe these two don’t work for NVMe) is similarly hot (measured by touching it - that’s the best I can do). Even if I were to completely ignore s-tui, I don’t think this could be the culprit.
    • Keyboard dongle was connected in both cases, and there is absolutely no way it uses that much power - even less likely than the NVMe.
    • And the USB flashdrive I’m booting Debian live from? That only adds extra to Debian’s power usage in this comparison. I removed it when booting DietPi.

And for lsmod… acpi_cpufreq is in both, but there’s a lot of other changes: Debian <-> DietPi - Diff Checker I’m not knowledgeable in this enough to know if any of those missing/added modules could affect power usage so much.

7

Changelog: https://metadata.ftp-master.debian.org/changelogs//main/l/linux-signed-amd64/linux-signed-amd64_6.1.38+2_changelog

Hmm, there are at least two AMD CPU patches. Unlikely that Debian adds such ja major bug with a tiny patch, but probably we want to rule it out?

cd /tmp
curl -fLo linux-meta.deb 'https://deb.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-amd64_6.1.38-1_amd64.deb'
curl -fLo linux.deb 'https://deb.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.1.0-10-amd64_6.1.38-1_amd64.deb'
apt install --allow-downgrade linux.deb linux-meta.deb

You will need to confirm the downgrade.

If you compare the midterm CPU times (1, 5 and 15 minutes averages) via uptime, they are moreless the same on DietPi and Debian? I also think that we can rule out the peripherals, but other than that, only CPU and GPU remains. And if CPU time is the same, also since frequency stats are similar, only voltage remains, which is controlled by the kernel.

Does the system have a dedicated graphics card, or does it use the GPU embedded with the CPU?

To 100% rule out the NVMe, you could install DietPi to a USB drive as well. But I do not believe that having the OS on NVMe without a USB drive attached can lead to such higher power usage, compared to having the OS on a USB drive and NVMe still attached, just unused.

8

The downgrade unfortunately didn’t fix the issue entirely, although it seems to have improved the power usage by a few watts. Still a 7-8W difference from Debian.
Fyi, for the last step, I did sudo dpkg -i linux.deb linux-meta.deb, because --allow-downgrade is not a valid flag on my install.

The load averages are all 0.00 in both cases after letting the system idle for half an hour.

I don’t have a dedicated GPU, just the integrated one.

Is the “Make your own distribution” script a good way to set up a production system? If yes, I may just do that to work around this strange issue.

9

Basically we use the script to build our images.

10

I see. Makes sense it didn’t help then. After running the script on the low-power-usage Debian install and rebooting, the power usage is back to the same levels as before… I don’t know what to try at this point. The difference is quite significant.

11

Is there anything I can still try to do something about this? I want to get my home server up and running, and I really wanted to use DietPi, but with this strange issue, I can’t.