{"id":13584,"date":"2026-10-17T07:50:00","date_gmt":"2026-10-17T05:50:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13584"},"modified":"2026-09-25T09:45:53","modified_gmt":"2026-09-25T07:45:53","slug":"raspberry-pi-clock-speed-cpu-governor-versus-throttling-and-what-vcgencmd","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/raspberry-pi\/tutorials-en-raspberry-pi\/raspberry-pi-clock-speed-cpu-governor-versus-throttling-and-what-vcgencmd\/","title":{"rendered":"Raspberry Pi Clock Speed: CPU Governor Versus Throttling and What vcgencmd get_throttled Reports"},"content":{"rendered":"

A Raspberry Pi reporting 700 MHz where the label says 1500 looks like a machine that has given up. The reading is real, and most of the time nothing at all is wrong.<\/p>\n

Two completely different mechanisms lower that number, and they have nothing to do with each other. One is the operating system saving power. The other is the firmware protecting the board. A single command says which of the two is at work.<\/p>\n

\n\"The
Four bits describe the present moment, four more describe the whole time since the last boot.<\/figcaption><\/figure>\n

Two reasons, one appearance<\/h2>\n

The first reason is ordinary and deliberate. Linux runs a small piece of code whose entire job is to keep the processor no faster than the work requires. Between two pieces of work it drops the clock, and it raises it again the moment something arrives.<\/p>\n

The second reason is a defence. Where the supply voltage sags or the chip gets too hot, the firmware lowers the clock itself, over the head of the operating system, to keep the board from misbehaving. That is throttling, and it is a symptom of something else.<\/p>\n

Both produce the same reading from the same command. The clock alone cannot tell them apart, which is why so many perfectly healthy boards get written off as failing.<\/p>\n

The governor and its ten steps<\/h2>\n

The code doing the everyday lowering is called a governor, and on a stock Raspberry Pi OS it is ondemand<\/code>.<\/p>\n

The board measured here offers ten steps: 600, 700, 800, 900, 1000, 1100, 1200, 1300, 1400 and 1500 MHz. The governor picks among them continuously, in milliseconds, from how busy the cores have been.<\/p>\n

A low reading is therefore a snapshot of a moment rather than a state. Sampling twenty times across six seconds caught 1500 MHz nineteen times and 600 MHz once – and that single sample, taken on its own, would have looked alarming.<\/p>\n

What get_throttled reports<\/h2>\n

The command that settles the question is vcgencmd get_throttled<\/code>. It answers with one hexadecimal number, and that number is a set of switches rather than a measurement.<\/p>\n

Each switch stands for one condition: supply voltage too low, clock capped, throttled, soft temperature limit reached. A switch that is on means the condition applies. The whole number reading zero means none of them do.<\/p>\n

The essential part is that this register knows nothing about the governor. Saving power sets no bit at all. A clock at 600 MHz next to throttled=0x0<\/code> is therefore not a contradiction – it is the answer.<\/p>\n

\n\"Two
\n<\/figure>\n

The number has two halves<\/h2>\n

Here is where the reading is most often misread. The four low bits describe the present moment. Four more, sixteen places higher up, record whether the same condition has occurred at any point since the machine last started.<\/p>\n

The consequence deserves stating plainly. A brief sag at three in the morning leaves the live bits clean by breakfast while the sticky bits still hold it. Checking the register once, in a quiet moment, and finding the low half at zero proves only that nothing is wrong at that instant.<\/p>\n

The sticky half is also cleared at every boot. Zeros on a machine that has been up for a minute mean nothing whatsoever; the same zeros after three weeks of uptime mean a great deal.<\/p>\n

What a real board reported<\/h2>\n

The board measured here is a Raspberry Pi 4 Model B, nineteen hours into its uptime, serving this site while the measurement ran.<\/p>\n

The register read 0x0<\/code> in every single sample, both halves, including the sample that caught the clock at 600 MHz. Temperature stayed between 57.4 and 59.9 \u00b0C throughout. The kernel log held no entry about voltage or throttling at all.<\/p>\n

The configuration is stock: arm_freq=1500<\/code>, no temperature limit set by hand, the governor untouched. Nothing was tuned here to produce a clean result.<\/p>\n

What to check when the suspicion remains<\/h2>\n

Where the sticky bits are set, the cause is more often the power supply than the heat, and the kernel makes that straightforward to confirm. It exposes a sensor named rpi_volt<\/code> alongside the temperature sensor, and it writes a line into the kernel log whenever the supply drops. An empty log is evidence in its own right.<\/p>\n

Where heat is the suspect, temperature belongs in a series rather than a single reading, and it needs taking while the board is busy. A value read after a minute of rest says almost nothing.<\/p>\n

And where the clock alone is the entire complaint, the register is the shortest path to an answer: one command, one number, and with it the difference between a processor resting and a board in difficulty.<\/p>\n

\n

Questions and answers<\/h2>\n

How can a value such as 0x50000 be decoded by hand?<\/h3>\n

The number is split into bits, and every bit that is set stands for one condition. The Raspberry Pi documentation assigns them as follows:<\/p>\n