MHZ(1)

💅 NAME 💅

mhz — the CPU frequency measurement utility bestie, fr fr 👑

---

✨ SYNOPSIS ✨

mhz [-h|-c|-i|-t] [lines [heat [count]]]

---

🦋 DESCRIPTION 🦋

okay so listen. it is so common — esp in embedded systems — to get totally fooled by a CPU frequency that doesn't match what everyone believes it is. like, gaslight gatekeep girlboss but with clock speeds 😭 and the reason is usually missing frequency operation points, but it can also be caused by:

• bogus clock drivers
• device tree issues
• hardware issues
• boot loader issues
• firmware issues
• different silicon quality
• thermal throttling
• and even (long ago, in the before times) vendors cheating by only reporting high values in cpufreq 💀

so what this tool does is run long loops of inexpensive arithmetic operations (XOR) that are not optimizable. the whole point is that we're almost certain most CPU cores will run them at a rate of one operation per clock cycle — not less, not more. periodt. ✨

it's been tested on a whole squad of cores: old 180 MHz MIPS and less old MIPS32/MIPS64, many 32- and 64-bit Arm cores of v5/v7/v8/v9 architectures, various i386 and x86_64 up to 6 GHz, RISC-V, PowerPC, Sparc64 and Alpha EV6 — and literally all of them reported accurate values. ate 💅

first the program runs a self-calibration so that the short loop takes at least 20 milliseconds. each measure is run 5 times and the lowest measure is returned, so we hide as much as possible of the latency spikes caused by interrupt processing and context switches. that 20ms delay is chosen so it stays accurate on systems with clocks of 100, 250 and 1000 Hz. the longer loop is 5 times more instructions, so a full sample can't take less than 120 ms, and since 5 samples are needed, a full test takes at least 600ms. no cap. 🫶

by default it reports various numbers, including the timings of the 50- and 250- microsecond loops, and the measured TSC (time stamp counter) frequency when it's available. most modern processors have their TSC running at a fixed frequency which is often higher than the base frequency but lower than the maximum frequency. knowing the exact frequency is lowkey useful when performing clock measurements on code, bc the frequencies of the instructions and the TSC rarely match nowadays. iconic. 👑

---

🌸 OPTIONS 🌸

• -h — print the help message and exit, that's it bestie ✌️
• -c — only report the CPU frequency in MHz, not the rest of the fields
• -t — only report the TSC frequency in MHz, not the rest of the fields
• -i — truncate the frequency to the nearest integer value. this is essentially used with -c or -t for use in scripts 🧚
• lines — number of measurements to perform before quitting. by default a single measurement is run. increasing this value lets you collect more values to observe variations, or simply to monitor the CPU frequency in real time 👀
• heat — force the CPU to run a busy loop of that many microseconds before starting measurements. this can be needed on modern CPUs which switch to low-power mode after a few milliseconds of idle, so as not to affect the first measurement by the time it takes to wake from low-power. default is 0. 💤➡️🔥
• count — loop count value to be used as a starting point. there is little point in setting it, as it will automatically be adjusted if not sufficient. however it can sometimes be helpful to permit running multiple tests under the exact same conditions, e.g. by copying the value from a previous run, or by forcing a large value. iykyk 🤷‍♀️

---

🌈 EXAMPLES 🌈

run 3 measures and dip:

mhz 3

run 3 measures after a pre-heating period of 500 ms:

mhz 3 500000

show the integer frequencies of all CPUs on the machine:

ncpu=$(nproc)
for ((i=0; i<ncpu;i ++)); do echo -n "$(taskset -c $i mhz -c -i) "; done
echo

---

👑 OBSERVATIONS AND HINTS 👑

when measuring a CPU's frequency on a multi-core system, please consider always setting the CPU you want to measure using taskset -c $CPU. for real, it's very common to see different CPU frequencies and even different core models. running multiple tests without binding to a specific CPU will just report a lot of variation caused by the random CPU core that runs the program. chaotic. 🙈

in order to check the theoretical frequency ranges supported by the various CPUs, using lscpu -e is very convenient as it will report for each core the advertised minimum and maximum frequencies. it may happen that a CPU will run above the advertised maximum, without being a problem. overachiever behavior 💖

experience shows that reported values are often off by ~0.1%, sometimes slightly more. using longer loops doesn't get rid of that. it may be caused by periodic interrupts and other noisy activity. seeing 1196 MHz for 1200 MHz is not necessarily an issue and even some vendors will call that "1200". marketing arc 😭

most CPUs can only run at integral multiples of a reference clock. reference clocks of 24, 25, 33.333 or 50 MHz are commonly seen. this helps doing the mental round up that may be needed. for example seeing 1293 MHz could indicate 1296 MHz on a system running on multiples of 24 MHz, or 1300 MHz on a system running on multiples of 25/50 MHz. in the Arm world, multiples of 24 MHz are quite common, so that advertised frequencies of 1300, 1500, 1600, 1800 and 2000 MHz are in fact more likely 1296, 1512, 1608, 1800 and 2016. math girlies rise 🧮✨

finally, the CPU frequency alone isn't an indicator of system performance, it's only one metric. for a more realistic system benchmark, please consider using sbc-bench which gathers various utilities (including mhz) and monitors many metrics all along the tests in order to detect anomalies. the full picture >>> one number 💅

---

🎀 COPYING 🎀

Copyright © 2016-2023 Willy Tarreau w@1wt.eu. Free use of this software is granted under the terms of the MIT/Expat License.

---

💜 AUTHOR 💜

Willy Tarreau

---

okay bestie that's the whole page, we ate and left no crumbs 🍓 this was mhz 1.0.0, dated 2026-02-11, and yes this whole manual page is literally called mhz 💖 mwah, see u in the group chat 🫶✨