CallMeter Docs

Hardware Clock Quality

Measures the accuracy of the remote sender's hardware clock by estimating crystal oscillator drift from RTCP Sender Reports.

Hardware Clock Quality (Clock Drift)

PropertyValue
Keyclock_drift_estimate
UnitParts per million (ppm)
TypeGauge
DirectionReceive
RFCRFC 3550 Section 6.4.1

What It Measures

Clock drift measures how accurately the remote endpoint's hardware clock keeps time compared to the reference clock. Every piece of hardware has a crystal oscillator that drives its internal clock, and no crystal is perfectly accurate. The deviation from perfect time is expressed in parts per million (ppm).

Think of it like a wristwatch that gains or loses a few seconds per day. A clock drift of 10 ppm means the remote device's clock gains or loses 10 microseconds for every second of real time — roughly 0.86 seconds per day.

CallMeter estimates clock drift by collecting RTCP Sender Report timestamps over time and applying linear regression across approximately 20 samples. The slope of the regression line reveals the systematic drift of the sender's clock.

Why It Matters

Clock drift affects media synchronization. If the sender's clock runs fast, the receiver will see RTP timestamps that advance faster than real time, causing the playout buffer to gradually deplete. If the clock runs slow, the buffer grows. Over long calls, significant drift can cause audio glitches, buffer underruns, or lip-sync issues in video calls.

For most enterprise VoIP equipment, clock drift is negligible. It becomes relevant in these scenarios:

  • Low-cost hardware — Cheap IP phones or gateways with inexpensive crystal oscillators may exhibit higher drift.
  • Virtualized environments — Virtual machines may have unstable clock sources, especially under CPU contention.
  • Long-duration calls — A small drift compounds over time. A 5 ppm drift accumulates to 18ms over one hour, which is within jitter buffer tolerance. But at 50 ppm, the same hour produces 180ms of drift.

How CallMeter Measures It

CallMeter collects NTP timestamps from RTCP Sender Reports and compares them against local wall-clock time. Using linear regression over a sliding window of 20+ samples, it estimates the systematic clock rate difference between sender and receiver.

Warmup Period

Clock drift estimation requires approximately 60 seconds of RTCP data to produce a reliable estimate. During this warmup period, the value may fluctuate as the regression model stabilizes. For calls shorter than 60 seconds, the estimate may not converge.

Thresholds

This metric does not have standard thresholds. Clock drift is an informational diagnostic that helps explain other symptoms:

Drift RangeTypical Source
Below 5 ppmHigh-quality hardware or NTP-disciplined clock
5 - 20 ppmStandard commercial equipment
20 - 100 ppmConsumer-grade or virtualized hardware
Above 100 ppmDefective oscillator or severely contended VM

What Causes High Clock Drift

  • Cheap crystal oscillators — Lower-cost hardware uses less accurate timing components.
  • Temperature variation — Crystal oscillator frequency varies with temperature. Equipment in poorly climate-controlled environments may drift more.
  • Virtualization — VMs that share CPU with other workloads may not get consistent access to hardware timers, causing apparent clock instability.
  • No NTP synchronization — Devices without NTP or PTP clock discipline will drift at their hardware's natural rate.

How to Fix It

  1. Enable NTP. Ensure all VoIP endpoints synchronize their clocks via NTP. This does not fix crystal drift directly but keeps the wall-clock reference accurate.
  2. Use quality hardware. Enterprise-grade SIP devices typically use TCXO (temperature-compensated crystal oscillator) components with drift below 5 ppm.
  3. Check VM clock sources. For virtualized endpoints, verify the guest is using a stable clock source (e.g., kvm-clock on Linux, VMware Tools on VMware).
  • Clock Skew — Measures the timing difference between sender and receiver clocks
  • Jitter — Clock drift can appear as low-frequency jitter
  • Timestamp Jumps — Sudden clock corrections may cause timestamp discontinuities

On this page