All the home lab servers are running 24 hours, 7 days. So power consumption is one of the critical facts of maintenance. Reduce it to save your electrical bill.
For my Proxmox VE machine.
The hardware specs:
- Motherboard: Gigabyte B450M DS3H
- CPU: AMD Ryzen 5 2400G
- RAM: 4X8GB 2400Mhz DDR4
- Storage: 1TB NVMe SSD, WD Blue SN570
- Network interface: PCIe 2.5Gbe
- Power Supply: Antec Earthwatts EA-500D, Max 500W.
- No keyboard, No mouse, No monitor attached.
I used a mini Ammeter to check the power consumption.
The running power reading is from 34W to 54W when I power on the machine and look at the meter for a while. After about 20 hours and 21 minutes, the total power consumption is 0.7957KWh. I did the calculation, the average is 39.11W.
I followed the guide at Unix.Cafe to change the CPU to powersave mode.
echo powersave | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
Check the current CPU mode,
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
The default mode is performance.
To change it back to default, enter the following:
echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
After changing the mode to powersave, I let it go about 1 day and 2 hours. The total power consumption is 0.7687KWh.
The average is about 29W.
It is almost a 25% reduction of the power. For a year or 365 days, I can save 87.6KWh.
In a year, it will use about 259KWh. Based on the cost of the electrical rate, it is $0.12/KWh. So the total is $31/year to run the Proxmox VE server at the home lab.
Go to some details of the Proxmox VE 8.0.3, which is powered by Debian 12. So I installed some tools to check the information.
apt install linux-cpupower apt install cpufrequtils apt install sysfsutils
To get the current state:
root@pve:~# cpupower frequency-info
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 1.60 GHz - 3.60 GHz
available frequency steps: 3.60 GHz, 2.30 GHz, 1.60 GHz
available cpufreq governors: conservative ondemand userspace powersave perform ance schedutil
current policy: frequency should be within 1.60 GHz and 3.60 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency: 1.60 GHz (asserted by call to hardware)
boost state support:
Supported: no
Active: no
Boost States: 0
Total States: 3
Pstate-P0: 3600MHz
Pstate-P1: 2300MHz
Pstate-P2: 1600MHz
Or run the old tool from cpufrequtils, cpufreq-info
root@pve:~# cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 4294.55 ms.
hardware limits: 1.60 GHz - 3.60 GHz
available frequency steps: 3.60 GHz, 2.30 GHz, 1.60 GHz
available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
current policy: frequency should be within 1.60 GHz and 3.60 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 2.30 GHz (asserted by call to hardware).
cpufreq stats: 3.60 GHz:23.53%, 2.30 GHz:1.79%, 1.60 GHz:74.68% (9165)
There are six cpufreq governors:
conservative
The CPUfreq governor “conservative”, much like the “ondemand”
governor, sets the CPU frequency depending on the current usage. It
differs in behaviour in that it gracefully increases and decreases the
CPU speed rather than jumping to max speed the moment there is any load
on the CPU. This behaviour is more suitable in a battery powered
environment. The governor is tweaked in the same manner as the
“ondemand” governor through sysfs with the addition of: freq_step, dwon_threshold, sampling_down_factor.
ondemand
The CPUfreq governor “ondemand” sets the CPU frequency depending on the
current system load. Load estimation is triggered by the scheduler
through the update_util_data->func hook; when triggered, cpufreq checks
the CPU-usage statistics over the last period and the governor sets the
CPU accordingly. The CPU must have the capability to switch the
frequency very quickly.
Sysfs files:
sampling_rate, sampling_rate_min, up_threshold, ignore_nice_load, sampling_down_factor, powersave_bias,
userspace
The CPUfreq governor “userspace” allows the user, or any userspace
program running with UID “root”, to set the CPU to a specific frequency
by making a sysfs file “scaling_setspeed” available in the CPU-device
directory.
powersave
The CPUfreq governor “powersave” sets the CPU statically to the
lowest frequency within the borders of scaling_min_freq and
scaling_max_freq.
performance
The CPUfreq governor “performance” sets the CPU statically to the
highest frequency within the borders of scaling_min_freq and
scaling_max_freq.
schedutil
The “schedutil” governor aims at better integration with the Linux
kernel scheduler. Load estimation is achieved through the scheduler’s
Per-Entity Load Tracking (PELT) mechanism, which also provides
information about the recent load [1]. This governor currently does
load based DVFS only for tasks managed by CFS. RT and DL scheduler tasks
are always run at the highest frequency. Unlike all the other
governors, the code is located under the kernel/sched/ directory.
The above info sheet is retrieved from Kernel.org official site.
To specify the governor to use at boot. Edit /etc/default/cpufrequtils (Create it if it doesn’t exit)
# valid values: userspace conservative powersave ondemand performance # get them from cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors GOVERNOR="conservative"
