Jitter is variation, not a diagnosis
Jitter is often used to describe variation in delay. The meaning of a reported number depends on the measurement and calculation behind it. A browser's HTTP round-trip estimate is not the same as a media application's packet-arrival statistic, and one high value does not locate a fault.
The earlier universal score table, guaranteed cable improvements, success percentages and exact UDP-probing claims are withdrawn here. This page explains the actual HTTP RTT estimator instead of treating those claims as measured findings.
Separate latency from variation
Latency describes a delay observation; variation describes how observations differ. VelocityVerify's idle value is the minimum HTTP RTT estimate after warm-up, while its jitter value smooths absolute differences between consecutive post-warm-up RTT inputs. Neither number alone describes every application path.
RFC 5481 discusses different delay-variation formulations and warns that round-trip observations do not readily identify one-way delay variation. The definition and direction matter when comparing tools.
Why there is no universal score table here
An application can buffer, recover or react differently to delay variation. This guide does not assign a universal good/bad threshold or infer access technology from a jitter value. A low smoothed estimate also does not prove there were no transient spikes.
Compare repeated observations made with the same method and conditions, then check symptoms in the affected application. A number of decimal places is not a guarantee of matching measurement accuracy.
Keep several possible causes open
The observation can be influenced by local wireless contention, queueing during other traffic, device load, browser scheduling, endpoint response and the wider path. This list is a set of possibilities, not a ranking of causes or proof of their frequency.
Separate the condition you changed from the one you are trying to explain. Moving rooms, changing devices and switching test services at the same time makes a before/after difference harder to interpret.
Use controlled checks before changing equipment
Write down the symptom, the device, the connection method, time and what else was using the connection. Keep failures and errors as well as successful runs. Use the following checks to narrow the question, not to promise a repair.
Compare wired and wireless conditions
Where practical, test the same computer connected to the router by Ethernet, then compare the location and Wi-Fi setup where the problem occurs. Record any adapter or device changes. A better wired result points toward investigating the local wireless condition; it does not certify that the rest of the service is fault-free.
No cable category guarantees a particular jitter figure or a fixed improvement. A test also transfers data, so consider metered allowances before repeating large transfers.
Compare quiet and busy periods
If symptoms appear mainly during transfers, compare quiet and busy observations using the same setup. A repeatable difference can make queueing a useful hypothesis; it does not identify a specific buffer from a browser result.
OpenWrt documents SQM as a way to manage latency under load, with CPU and configuration limitations. Check the exact device and firmware documentation before changing settings. Keep a recoverable baseline and evaluate both responsiveness and throughput.
Record line symptoms without assuming the cause
Record disconnects, modem warnings and whether more than one device is affected. Ask the provider which line or equipment checks are appropriate for the service. This guide does not infer a coax fault from an RTT statistic or recommend altering provider-owned or shared wiring.
Repeat at different times
Keep the device, connection method and test endpoint as consistent as possible. Note the time and concurrent activity. A repeated evening difference supports further investigation, but timing alone does not prove an oversubscribed neighborhood node, throttling or deliberate prioritization.
Read the VelocityVerify estimator
Contract http-rtt-v1 times full HTTP completion with performance.now(). The default idle sequence has ten attempts, with one warm-up excluded. For post-warm-up inputs below 1 ms, the existing worker rule substitutes the previous estimate and then applies a 1 ms floor if needed. Those transformed inputs, not raw packet arrival times, feed the calculation.
Take the absolute difference between consecutive post-warm-up inputs. The first such difference initializes jitter. For later differences above the current estimate, the update is 0.3 × old jitter + 0.7 × difference; otherwise it is 0.8 × old jitter + 0.2 × difference. The result is displayed to two decimal places.
As an illustrative calculation, post-warm-up inputs of 10, 30 and 20 ms produce differences of 20 and 10 ms. Jitter initializes to 20, then becomes 0.8 × 20 + 0.2 × 10 = 18 ms. This is an example, not a field result.
The worker does not send UDP or ICMP packets. HTTP errors and invalid timing fail the sequence rather than yielding a numeric jitter result. The per-request budget is 2,000 ms, with a 20,000 ms sequence deadline. A failed or absent estimate is not zero. These budgets bound waiting and are not quality thresholds.
Keep application evidence alongside the test
Record the application's own symptoms, server region if known, time and any error. A call or game may not use the diagnostic endpoint's path. Do not substitute a smoothed browser estimate for the application's own packet-loss, delay or recovery evidence.
The timing basis changed from the earlier Resource Timing substitution to full HTTP completion. Preserve the method version before comparing older observations. Shared URLs and local records are not authenticated measurements.
Run a diagnostic and retain the conditions and any errors. A result is an observation, not a provider verdict.