Choosing a Linux Clocksource: TSC vs. HPET for Database Servers

1. Why clocksource matters for database performance

Every time an application on Linux queries the current time, for example via clock_gettime(), the kernel relies on a so called clocksource: a hardware time source that provides a monotonically increasing counter. MySQL uses such timestamps for performance schema measurements, slow query log entries, and internal timeout calculations. PHP-FPM uses them for request timing and slowlog entries. Both systems perform thousands of such time queries per second, and the speed of these queries depends directly on the chosen clocksource.

The Time Stamp Counter (TSC) is by far the fastest available clocksource on modern x86 hardware, because it can be read directly as a CPU register without taking a detour through slower external hardware such as the High Precision Event Timer (HPET). The difference is not an academic footnote: a single TSC access typically costs a few nanoseconds, while an HPET access, which goes through the I/O bus, can easily take ten to a hundred times longer.

For a Magento database server with a high transaction rate, this difference adds up over millions of time queries per day into a measurable CPU load that is often overlooked in benchmarks, because it does not show up as a single conspicuous metric but is spread out into a diffuse, system wide baseline load.

2. The Linux kernel's clocksource subsystem

This subsystem operates completely unnoticed in the background during normal operation, which is why many administrators only become aware of it once a misconfiguration or an unusual hardware combination causes problems.

Linux abstracts time measurement through its own subsystem, which registers several available hardware time sources and automatically selects the presumed best one at boot. Each clocksource carries an internal rating that reflects its precision and reliability. On systems where the kernel classifies the time source as stable, TSC receives the highest rating and is therefore used by default, provided there are no known problems with that particular CPU generation.

In addition to automatic selection, the active clocksource can be manually overridden at any time, both temporarily at runtime and permanently via a kernel boot parameter. This flexibility matters because not every hardware or virtualization environment reliably supports TSC, and manual intervention is sometimes necessary to work around known issues with a specific chipset generation or hypervisor configuration.

# List all clocksources the kernel considers available on this hardware
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

# Show the clocksource currently in active use
cat /sys/devices/system/clocksource/clocksource0/current_clocksource

3. TSC: the Time Stamp Counter in detail

A basic understanding of these hardware properties makes it easier to correctly interpret TSC related kernel messages, instead of dismissing them as generic system log noise.

The Time Stamp Counter is a counter register implemented directly in the CPU that increments on every clock cycle, or on modern CPUs runs at a constant, clock independent rate (Invariant TSC). Access happens through the RDTSC assembly instruction, which can be executed directly from userspace without a system call or ring transition, resulting in extremely low latency.

Historically, TSC had a well known problem: on systems with multiple CPU cores, the counter could drift slightly between cores, causing two consecutive time queries on different cores to appear to go backwards. Frequency scaling (SpeedStep, Turbo Boost) could also affect early TSC implementations, since the counter used to be tied to the actual CPU clock frequency. Modern CPUs solve this problem through what is called an Invariant TSC, which runs at a constant rate independent of frequency scaling and C-states and is kept synchronized across cores.

Whether a CPU has a reliable Invariant TSC can be read directly from the CPU flags in /proc/cpuinfo on Linux. The constant_tsc and nonstop_tsc flags indicate that the kernel trusts this time source and uses it without reservation as the primary clocksource. If these flags are missing, the kernel classifies TSC as potentially unreliable and automatically falls back to a slower but more stable alternative.

# Check whether the CPU exposes a reliable, invariant TSC
grep -o 'constant_tsc\|nonstop_tsc' /proc/cpuinfo | sort -u

# Check kernel messages for TSC-related warnings at boot
dmesg | grep -i tsc

4. HPET and other clocksources as a fallback

These fallback mechanisms are not a design flaw but a deliberate safety measure by the kernel against inconsistent time measurement on hardware whose TSC behavior cannot be fully trusted.

The High Precision Event Timer (HPET) is dedicated timer hardware on the mainboard that provides a precise but noticeably slower time source, independent of CPU clock and frequency scaling. Since access to HPET happens via memory mapped I/O instead of a direct CPU register, every single access carries noticeably higher latency than a TSC access. The kernel mainly uses HPET when TSC is classified as unreliable, or on older or virtualized hardware without invariant TSC support.

Besides HPET, Linux knows other clocksources such as acpi_pm (the ACPI Power Management Timer) and, in virtualized environments, specialized paravirtualized time sources such as kvm-clock or xen. These alternatives generally deliver noticeably lower performance than a reliable TSC, but in situations where TSC does not function trustworthily, they are the safer choice, since inconsistent time measurement can have far more serious consequences for database transaction logic and replication timing than a somewhat slower but correct time source.

5. Checking and switching the active clocksource

Before making a manual switch, the currently active clocksource should always be documented first, so that a change remains traceable afterward and can be quickly reverted if problems arise.

The currently used clocksource can be read at any time through the sysfs interface under /sys/devices/system/clocksource/clocksource0/. A manual runtime switch is possible through the same interface by writing the desired value into the current_clocksource file, which is practical for quick tests but does not persist after a reboot.

For a permanent configuration, the desired clocksource is set as a kernel boot parameter in the GRUB configuration. This is especially relevant when the automatically chosen default conservatively falls back to a slower time source for safety reasons, even though the hardware in question demonstrably has a reliable Invariant TSC and manually forcing tsc would be justified.

# Switch clocksource at runtime (not persistent across reboots)
echo tsc | sudo tee /sys/devices/system/clocksource/clocksource0/current_clocksource

# Verify the change took effect
cat /sys/devices/system/clocksource/clocksource0/current_clocksource

# /etc/default/grub — force TSC persistently at boot
GRUB_CMDLINE_LINUX_DEFAULT="quiet clocksource=tsc tsc=reliable"

# After editing, regenerate the boot configuration:
# update-grub  (Debian/Ubuntu)
# grub2-mkconfig -o /boot/grub2/grub.cfg  (RHEL/CentOS)

6. Why clock_gettime matters for MySQL and PHP

The effect concerns not just the absolute response time but also the spread of latencies, which is particularly relevant for monitoring systems relying on p95 and p99 metrics.

MySQL calls clock_gettime() internally in very many places: for the performance schema, for lock timeout monitoring, for timestamps in the slow query log, and for internal timing of query execution. With a high number of concurrent connections and queries, as a busy Magento shop generates, these calls accumulate into a substantial total per second. On a slow clocksource such as HPET, this overhead alone can lead to a noticeable additional CPU load that does not show up as its own line in any profiling tool, because it is distributed across countless individual calls.

PHP-FPM shows a similar pattern: request timing, slowlog timestamps, and internal metrics also use clock_gettime(), often several times per request. With thousands of requests per minute on a Magento web server, a slow clocksource can raise the average response time by a small but measurable amount that only shows up in a direct before and after comparison between TSC and HPET, not when looking at a single isolated request.

7. Virtualization: kvm-clock and TSC in VMs

For mixed Magento hosting environments combining bare metal database servers with virtualized web servers, it is worth considering both server types separately, since the clocksource recommendation can differ significantly between them.

In virtualized environments, choosing a clocksource is more complicated because the hypervisor introduces additional uncertainty. A direct TSC access from within a virtual machine must be intercepted or emulated by the hypervisor, which performs differently in terms of speed and reliability depending on the virtualization technology and configuration. KVM offers kvm-clock, a paravirtualized clocksource specifically designed for use in virtual machines, providing a good compromise between performance and reliability.

Modern CPU generations with full TSC virtualization support (such as Intel VMX TSC Scaling or AMD TSC Ratio) now allow the guest system to use TSC directly and with almost no overhead, even inside a virtual machine. Whether this is the case depends on the combination of host CPU, hypervisor version, and the specific VM configuration, and should be explicitly tested before a production migration rather than relying on default assumptions. On older virtualization setups or with nested virtualization, kvm-clock often remains the more reliable choice compared with forcing TSC.

8. Diagnosing clocksource related latency spikes

This diagnostic step belongs in every systematic latency investigation, precisely because it is so easily overlooked once more obvious causes such as disk I/O or lock contention have already been ruled out.

If a system shows unexplained, small latency spikes that cannot be explained by disk I/O, network, or CPU load, it is worth checking the active clocksource. A simple but informative test measures the raw call time of clock_gettime() in a loop with a small test program or with perf stat, to reveal the actual cost per time query on the specific system.

Another diagnostic tool is dmesg, which logs warnings at boot when the kernel classifies TSC as unreliable and automatically falls back to a different clocksource. Such messages are frequently overlooked in practice because they appear among many other lines during the boot process, but they often explain in hindsight why a system responds minimally slower under load than an identical server with a working Invariant TSC.

# Measure raw clock_gettime overhead with perf
perf stat -e task-clock -r 10 -- \
  bash -c 'for i in $(seq 1 1000000); do :; done'

# A more targeted micro-benchmark can be built with a tiny C loop
# calling clock_gettime(CLOCK_MONOTONIC, &ts) in a hot loop and
# comparing wall-clock time under different clocksources

9. TSC, HPET, and kvm-clock side by side

The following table summarizes the key properties of the most common clocksources for database servers.

The table shows: TSC remains the clearly superior choice on suitable hardware, while HPET and acpi_pm should only serve as a safety net for systems where the kernel justifiably distrusts TSC.

10. Summary

The chosen clocksource affects every single time measurement that MySQL and PHP-FPM perform on a Linux server, from slow query logs to request timing. TSC is by far the fastest time source on modern hardware with invariant TSC support, because it is read directly from a CPU register without a system call, while HPET serves as a noticeably slower but more reliable fallback when the kernel classifies TSC as potentially unstable.

In virtualized environments the situation is more complex: kvm-clock offers a solid compromise, while modern TSC scaling in current hypervisor versions can enable direct TSC access with near bare metal performance. The actual configuration should always be validated via /proc/cpuinfo, dmesg, and the sysfs interface, rather than relying on default assumptions about the respective hardware or virtualization environment.

11. FAQ: Clocksource TSC vs. HPET