You just upgraded your kernel or tweaked your BIOS power settings, and your desktop feels sluggish. You need to know if the hardware is actually bottlenecked or if a runaway service is stealing cycles. You open the terminal to run a benchmark, but you are staring at a dozen different tools and conflicting forum advice.
What is actually happening
Benchmarking is not about chasing a single composite score. It is about establishing a reliable baseline. Think of it like a mechanical diagnostic. You are not trying to win a race. You are checking if the engine runs smoothly under sustained load, if the storage responds instantly to small requests, and if the network pipe delivers consistent throughput. Fedora provides specialized tools for each subsystem because a generic system score hides the actual failure point. When you run these tests, you are forcing each component to operate at its design limits so you can measure latency, throughput, and thermal behavior under controlled conditions. The kernel schedules I/O, manages CPU frequency scaling, and handles network buffers. Your benchmark simply applies enough pressure to make those subsystems reveal their limits.
CPU benchmark
The central processor handles everything from package compilation to window compositing. You need a tool that stresses integer and floating-point units across all available cores. sysbench is the standard for quick, repeatable CPU scoring. It runs a prime number calculation loop that scales cleanly with thread count and bypasses most kernel caching layers.
Here is how to run a multi-threaded CPU test that matches your hardware topology.
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run
# --cpu-max-prime sets the upper bound for prime number generation
# $(nproc) dynamically matches the thread count to your physical cores and hyperthreads
# run executes the test immediately without a separate prepare or cleanup phase
The output will show operations per second and average latency. Run the command three times. Discard the first run. The CPU governor needs a few seconds to shift from powersave to performance mode. Record the average of the remaining two runs.
If you suspect thermal throttling is capping your performance, stress-ng applies a heavier, sustained load that reveals frequency drops.
stress-ng --cpu $(nproc) --cpu-method matrixprod --timeout 60 --metrics-brief
# --cpu-method matrixprod uses matrix multiplication to stress both integer and FPU units
# --timeout 60 runs the test for exactly sixty seconds to trigger thermal limits
# --metrics-brief prints only the final summary instead of verbose per-second updates
Watch the avg-cpu and load lines. If your reported MHz drops significantly during the sixty seconds, your cooling solution or BIOS power limits are intervening. Check journalctl -xeu thermald if you see sudden frequency drops. The thermald daemon actively manages CPU power states to prevent overheating. Fedora enables it by default on laptops and thin clients.
Run the test three times. Average the last two. Ignore the first run.
Disk I/O benchmark
Storage performance dictates how fast applications launch and how smoothly your desktop responds. Sequential throughput matters for large file transfers. Random 4K latency matters for everything else. fio is the industry standard because it simulates real-world I/O patterns rather than just filling a buffer. It bypasses the page cache when configured correctly, forcing the kernel to talk directly to the storage controller.
Here is how to test random read performance, which directly correlates with desktop responsiveness.
fio --name=randread --ioengine=libaio --rw=randread --bs=4k --numjobs=4 \
--size=1G --runtime=30 --group_reporting --filename=/tmp/fio_test
# --ioengine=libaio uses Linux native asynchronous I/O for accurate throughput measurement
# --rw=randread isolates random read operations to measure latency
# --bs=4k matches the standard block size for database and desktop workloads
# --numjobs=4 simulates four concurrent applications accessing the disk simultaneously
# --runtime=30 stops the test after thirty seconds to prevent unnecessary wear
# --group_reporting consolidates the output so you read one summary instead of four
Clean up the test file immediately after the run.
rm /tmp/fio_test
# removes the temporary file to reclaim space and prevent stale data from skewing future tests
A quick sequential write check is useful for verifying backup speeds or large file copies. dd is simple but lacks the I/O scheduling awareness of fio.
dd if=/dev/zero of=/tmp/ddtest bs=1M count=2048 conv=fdatasync && rm /tmp/ddtest
# if=/dev/zero generates a continuous stream of null bytes for pure write testing
# conv=fdatasync forces the kernel to flush the write cache to disk before reporting completion
# rm /tmp/ddtest cleans up the two gigabyte test file immediately
Fedora mounts /tmp as a tmpfs by default on most Workstation installations. This means your test runs in RAM, not on your physical disk. If you need to benchmark the actual storage device, create a test file in your home directory or use a dedicated test partition.
Test random 4K latency, not just sequential throughput. Desktop lag lives in the small reads.
GPU benchmark
Graphics performance depends entirely on your driver stack. Intel and AMD GPUs use the open-source mesa stack. NVIDIA cards require proprietary drivers. You need to match the benchmark to your rendering API.
glmark2 runs a series of OpenGL workloads and calculates a composite score based on frame pacing and rendering complexity.
glmark2
# runs the default OpenGL test suite and outputs a final score
# use --off-screen if you want to test without a visible window
# use --display=wayland if your session runs on Wayland instead of X11
For Vulkan workloads, the vulkan-tools package provides validation and basic performance checks.
sudo dnf install vulkan-tools
# installs the official Vulkan utility suite from the Fedora repositories
vulkaninfo --summary
# prints the active GPU, driver version, and supported Vulkan extensions
NVIDIA users should monitor real-time utilization during any workload. nvtop provides a terminal-based dashboard that tracks GPU clocks, memory usage, and power draw.
nvtop
# launches a real-time monitoring interface for NVIDIA GPUs
# press q to exit the dashboard when the workload completes
If glmark2 crashes or prints a display initialization error, your session compositor or driver configuration is misaligned. Check your active display server with echo $XDG_SESSION_TYPE. Wayland and X11 require different initialization flags for off-screen rendering.
Match the benchmark to your driver stack. OpenGL for desktop compositing, Vulkan for modern games.
Network throughput benchmark
Network tests fail when you blame the NIC instead of the switch, or when you test over WiFi instead of Ethernet. iperf3 measures raw TCP and UDP throughput between two endpoints. It requires a server process on one machine and a client process on another.
Start the server process on the target machine.
iperf3 -s
# launches the iperf3 server and listens on the default port 5201
# the server will block the terminal until you press Ctrl+C
Run the client process on your Fedora machine.
iperf3 -c 192.168.1.100 -t 30 -P 4
# -c specifies the server IP address or hostname
# -t 30 runs the test for thirty seconds to stabilize TCP window scaling
# -P 4 opens four parallel streams to saturate modern gigabit or 2.5G links
The output will show Send Buffer, Receive Buffer, and Bandwidth. Compare the Bandwidth column to your cable rating. A gigabit connection should peak near 940 Mbps due to Ethernet framing overhead. If you see 300 Mbps on a wired link, your switch port is negotiating at 100 Mbps full duplex. Check ethtool <interface> to verify the link speed and duplex mode.
Test over wired Ethernet only. WiFi variables make throughput numbers meaningless.
Verify it worked
A benchmark only proves something is broken if the numbers are consistent and the tool exits cleanly. Check the exit code immediately after the run.
echo $?
# prints 0 if the command completed successfully
# prints a non-zero value if the tool encountered a fatal error or permission denial
Look for warning lines in the output. fio will print a direct I/O warning if your filesystem does not support it. sysbench will complain if the prime calculation limit is too low for your core count. Run the same test twice. If the variance exceeds ten percent, your system is not idle. Close background applications, disable automatic updates temporarily, and run again.
Check the exit code before trusting the numbers. Variance kills accuracy.
Common pitfalls and what the error looks like
Background services skew every benchmark. Package managers, desktop search indexers, and cloud sync clients will trigger disk I/O and CPU spikes at random intervals. Freeze them during the test.
systemctl mask packagekit.service flatpak-system-helper.service
# prevents automatic package checks and flatpak background tasks from interrupting the test
# run systemctl unmask <service> after you finish benchmarking
If fio fails with a permission denial, you are likely running the command inside a restricted container or a user namespace that blocks direct I/O. Switch to a regular terminal session or run the test in your home directory. You will see this exact warning when the kernel rejects the I/O engine request.
fio: io_u_queue: Cannot allocate memory
fio: io_u_queue: direct I/O not supported on this filesystem
If iperf3 hangs on Connecting to host, your firewall is blocking port 5201. Allow the traffic temporarily.
sudo firewall-cmd --add-port=5201/tcp --timeout=60
# opens the iperf3 port for sixty seconds without modifying the persistent firewall rules
SELinux does not block these benchmarks by default, but if you see denied messages in journalctl -t setroubleshoot, your custom script or modified binary is running in an unconfined context. Restore the default context with restorecon -v <file> before rerunning.
Freeze background services before the test. Variance is the enemy of accurate baselines.
When to use this vs alternatives
Choose the right tool for the specific subsystem you are diagnosing. Use sysbench when you need a repeatable CPU score to compare kernel updates or compiler flags. Use stress-ng when you want to trigger thermal limits and verify cooling behavior under sustained load. Use fio when you need to measure random read/write latency for databases or desktop responsiveness. Use dd when you only need a quick sequential throughput check and do not care about I/O scheduling accuracy. Use glmark2 when you are troubleshooting desktop compositor performance or OpenGL driver regressions. Use vulkaninfo when you need to verify Vulkan driver support and extension availability. Use iperf3 when you are measuring raw link throughput between two wired endpoints. Use speedtest-cli when you only care about internet service provider latency and public server routing.
Pick the tool that matches the symptom. Do not run a CPU stress test to diagnose a slow disk.