-
Notifications
You must be signed in to change notification settings - Fork 1
drift_ns
drift_ns is the high-precision counterpart to drift_ms. It measures the signed nanosecond deviation from the nearest hardware VSync pulse. While most OSD metrics are rounded for readability, drift_ns is intended for programmatic analysis, clock-skew detection, and debugging sub-millisecond jitter.
- Positive Value (+): The frame was presented late relative to the nearest pulse.
- Negative Value (-): The frame was presented early relative to the nearest pulse.
- Zero (0): The frame is perfectly phase-locked with the hardware.
Mnemonic: Think of the VSync pulse as time zero. Negative values are "before zero" (early), positive values are "after zero" (late).
At high refresh rates, millisecond precision becomes insufficient for deep analysis. A drift of "0.4ms" might look small in the OSD, but it represents 400,000 nanoseconds.
By tracking drift_ns, you can observe patterns that are invisible at the millisecond level, such as the microscopic "creep" of a software timer or the nanosecond-level noise introduced by the Linux kernel's interrupt handler.
| Metric | Best For |
|---|---|
| drift_ms | OSD display, quick human readability, coarse trend analysis. |
| drift_ns | Log analysis, clock-skew detection, sub-millisecond jitter debugging. |
drift_ns is a modulo calculation. It does not measure the total time since the application started; it measures the offset from the current closest heartbeat.
Because this is a modulo operation against the nearest pulse, drift_ns always falls in the range [−ideal_ns/2, +ideal_ns/2]. A value of +4,166,666 ns at 120Hz is functionally identical to −4,166,666 ns, both represent the worst-case mid-cycle alignment.
The primary "Guru" use for drift_ns is identifying Clock Skew. Your GPU and monitor have separate crystal oscillators that are never perfectly identical.
If you log drift_ns over several minutes of a "perfect" 120 FPS run, you will likely see the value slowly and linearly crawl (e.g., adding 500ns every frame). This is the physical reality of two hardware devices running at slightly different speeds. Eventually, this drift will accumulate until the compositor is forced to skip or repeat a VBlank to realign.
drift_ns is the raw input used to calculate the Sync Quality Score.
Note: This is the same formula used for the sync score, but using nanosecond units. The result is identical, only the precision of the input differs. Use the raw nanoseconds to distinguish between:
- True Jitter: Randomly bouncing nanoseconds (indicates OS interference).
- Fixed Offset: A stable but non-zero nanosecond count (indicates a deliberate compositor delay).
- Linear Drift: A steady climb or fall (indicates hardware clock mismatch).
Use this table to assess whether observed drift is meaningful or just measurement noise (±1–2µs noise is normal due to thread race conditions).
| Refresh Rate | 1% of Frame | 0.1% of Frame | "Negligible" Threshold |
|---|---|---|---|
| 60Hz (16.67ms) | ±166,667 ns | ±16,667 ns | < ±10,000 ns |
| 120Hz (8.33ms) | ±83,333 ns | ±8,333 ns | < ±5,000 ns |
| 360Hz (2.77ms) | ±27,778 ns | ±2,778 ns | < ±2,000 ns |