monotonic: x86 linux, unable to determine clock rate

Error message

monotonic: x86 linux, unable to determine clock rate

What it means

Emitted during monotonicInit_x86linux() (only when built with -DUSE_PROCESSOR_CLOCK on x86_64 Linux) when the regex '^model name\s+:.*@ ([0-9.]+)GHz' fails to match any line in /proc/cpuinfo, leaving mono_ticksPerMicrosecond at 0. Because the TSC tick rate is unknown, the function returns without assigning getMonotonicUs, so Redis falls back to the POSIX clock_gettime(CLOCK_MONOTONIC) path. It is a warning to stderr, not fatal.

Source

Thrown at src/monotonic.c:87

                double ghz = atof(&buf[pmatch[1].rm_so]);
                mono_ticksPerMicrosecond = (long)(ghz * 1000);
                break;
            }
        }
        while (fgets(buf, bufflen, cpuinfo) != NULL) {
            if (regexec(&constTscRegex, buf, nmatch, pmatch, 0) == 0) {
                constantTsc = 1;
                break;
            }
        }

        fclose(cpuinfo);
    }
    regfree(&cpuGhzRegex);
    regfree(&constTscRegex);

    if (mono_ticksPerMicrosecond == 0) {
        fprintf(stderr, "monotonic: x86 linux, unable to determine clock rate\n");
        return;
    }
    if (!constantTsc) {
        fprintf(stderr, "monotonic: x86 linux, 'constant_tsc' flag not present\n");
        return;
    }

    snprintf(monotonic_info_string, sizeof(monotonic_info_string),
            "X86 TSC @ %ld ticks/us", mono_ticksPerMicrosecond);
    getMonotonicUs = getMonotonicUs_x86;
}
#endif

#if defined(__aarch64__)
static long mono_ticksPerMicrosecond = 0;

/* Read the clock value.
 * CNTVCT_EL0 is a system counter register, that provides the monotonic

View on GitHub (pinned to 3acc0c49cf)

Solutions

Ignore it if acceptable — Redis transparently falls back to clock_gettime(CLOCK_MONOTONIC) and runs correctly, just slightly slower on clock reads.
Rebuild without -DUSE_PROCESSOR_CLOCK (the default) to silence the message and use POSIX monotonic time.
Inspect /proc/cpuinfo to confirm the model-name format; if your platform genuinely exposes constant_tsc and a known GHz, the upstream regex may need extension.
On a host where the message is noise, redirect stderr or log it at debug level rather than treating it as an error.

Example fix

// before: built with processor clock, AMD CPU has no @GHz in /proc/cpuinfo
$ make CFLAGS="-DUSE_PROCESSOR_CLOCK"
// after: use default POSIX monotonic clock
$ make

Defensive patterns

Strategy: fallback

Validate before calling

#!/usr/bin/env bash
# On x86 Linux, redis derives the TSC frequency from cpuinfo/cpuinfo_max_freq.
# If it can't, it logs this warning and falls back. Pre-check so you know the box is affected.
if [ "$(uname -m)" != "x86_64" ]; then exit 0; fi
if [ ! -r /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq ]; then
  echo "no cpufreq cpuinfo_max_freq -> redis will warn on clock rate" >&2
fi
# 'constant_tsc' must be in cpu flags or the fast path is abandoned.
if ! grep -qw constant_tsc /proc/cpuinfo; then
  echo "constant_tsc absent -> monotonic clock rate warning expected" >&2
fi

Type guard

// No typed value to narrow: this is a host-capability probe, not data validation.
// Model the probe result instead.
export interface MonotonicSupport { clockRateKnown: boolean; constantTsc: boolean; }
export function isMonotonicSupport(o: unknown): o is MonotonicSupport {
  return typeof o === 'object' && o !== null
    && typeof (o as MonotonicSupport).clockRateKnown === 'boolean'
    && typeof (o as MonotonicSupport).constantTsc === 'boolean';
}

Try / catch

// The warning is non-fatal: capture it from stderr and log, but do not abort.
import { spawn } from 'node:child_process';
const proc = spawn('redis-server', [confPath]);
proc.stderr.on('data', chunk => {
  const s = chunk.toString();
  if (/unable to determine clock rate/.test(s)) {
    log.warn('redis monotonic clock fallback on this host; expect lower-res event timing');
  }
});

Prevention

Run Redis on hosts whose CPU advertises 'constant_tsc' (grep /proc/cpuinfo).
Ensure cpufreq cpuinfo_max_freq is readable; avoid minimal containers that mask /sys.
Pin redis to a kernel/CPU combo you have tested so the monotonic path is known-good.
Treat the warning as informational, not fatal: Redis keeps working via a fallback clock.
Don't deploy Redis under virtualization that hides TSC info without first verifying the clock path.

When it happens

Trigger: Built redis-server with CFLAGS='-DUSE_PROCESSOR_CLOCK' on an x86_64 Linux host whose /proc/cpuinfo 'model name' line lacks an '@ X.YYGHz' token (e.g. AMD/Epyc, custom/embedded CPUs, virtualized CPUs that report a non-standard model string, or a kernel that omits the GHz suffix).

Common situations: AMD processors and many cloud/virtualized environments report CPU model names without the '@ N.NGHz' format Intel uses, so the regex never matches. Also seen on kernels where the model-name format changed. The server still runs (POSIX fallback) but loses the faster TSC-based monotonic clock.

Related errors

AI-assisted analysis of redis/redis@3acc0c49cf (2026-08-01). Data as JSON: /data/errors/88c378e131bbc668.json. Report an issue: GitHub.