Raspberry Pi Clock Speed: CPU Governor Versus Throttling and What vcgencmd get_throttled Reports

A Raspberry Pi running below its nominal CPU speed is not necessarily faulty. The governor is the software that selects the requested CPU frequency. It can request a lower frequency when demand falls. Temperature limits, insufficient supply voltage and configured frequency limits can also affect the result. Clock speed alone does not identify the cause.

Governor, limits and actual clock

Linux CPUFreq combines a policy, a governor and a hardware driver. The governor selects a performance request within the configured limits; the hardware does not have to deliver that exact frequency. The active governor and available frequency steps depend on the board, operating system, kernel and configuration. Neither ondemand nor ten steps between 600 and 1500 MHz is a universal Raspberry Pi default.

scaling_cur_freq often represents the last requested frequency rather than an exact hardware measurement. vcgencmd measure_clock arm reports the Arm clock in hertz. Comparing values requires matching units and allowing for the time between readings.

Status alongside the clock

The following commands only read information on a Raspberry Pi system that provides vcgencmd and CPUFreq policy0. Missing commands or files indicate an unavailable interface, not a healthy status:

vcgencmd get_throttled
vcgencmd measure_clock arm
vcgencmd measure_temp
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq

The CPUFreq limits are in kilohertz; dividing by 1000 gives megahertz. The clock reported by measure_clock is in hertz; dividing by 1,000,000 gives megahertz. measure_temp reports the SoC temperature. The commands run one after another, so the readings describe slightly different moments.

Repeated readings during the workload where the slowdown occurs are more useful than one idle sample. Recording timestamps, board model, software versions and uptime makes the observations comparable. No governor change or stress test is necessary to collect this basic information.

What the eight documented bits mean

vcgencmd get_throttled returns a hexadecimal bit mask: a number that combines several yes/no status indicators. Each set bit reports a condition; the value is neither a voltage measurement nor a performance score.

The upper four flags record occurrence, normally since boot, rather than a time, duration or count. A reboot begins a new observation period. Historical undervoltage and throttling flags do not establish that both events happened simultaneously.

Three examples, with different conclusions

• 0x0: none of the documented current or historical conditions is reported. A low clock can still reflect the governor or configured policy limits. Zero is not a complete hardware health certificate.
• 0x50000: bits 16 and 18 are set. Undervoltage and throttling have occurred; none of the four current flags is set. The mask alone does not identify a defective power supply.
• 0x50005: bits 0, 2, 16 and 18 are set. Undervoltage and throttling are also reported at the time of reading.

A constructed example of 600 MHz alongside 0x0 is therefore compatible with normal frequency scaling, but does not prove that explanation. Governor, policy limits and workload provide the missing context.

Temperature and power need separate evidence

The soft temperature limit is model-specific: the documented temp_soft_limit setting applies to Raspberry Pi 3A+/3B+. That threshold must not be used as a general rule for a Pi 4 or Pi 5. Cooling decisions should follow the model documentation and temperature observations under the relevant workload.

Undervoltage can involve the supply, cable, connectors or attached devices. The relevant voltage is the voltage reaching the board. The official Pi 4/400 supply is specified at 5.1 V and 3 A; different models have different requirements. A label stating 5 V alone neither establishes suitability nor proves a fault.

The Linux raspberrypi-hwmon driver periodically checks a firmware property for undervoltage. It is not a continuous precision voltmeter. Kernel messages can add evidence, but an empty log cannot exclude a brief event, missing driver support or unavailable log history.