What the result means

Loaded latency asks whether requests took longer while this test was downloading. Under contract http-rtt-v1, VelocityVerify reports a mean HTTP RTT delta only when the selected sample plan, idle baseline and phase evidence are valid. It does not assign a new letter grade or isolate the device responsible for an increase.

The earlier P90, bidirectional-grade, anti-prioritization and residential-grade-share claims are withdrawn here. The available implementation did not support those descriptions. The earlier self-assigned methodology score was not an independent review.

Start with the actual idle estimate

Idle latency is useful context, but it does not describe a busy connection by itself. The default worker sequence makes ten HTTP attempts: one warm-up and nine post-warm-up estimator inputs. The reported baseline is the minimum after warm-up, not a median. A below-1-ms input uses the previous estimate and then a 1 ms floor if necessary.

These are full HTTP completion-time observations using a monotonic browser clock. They include endpoint and browser effects, not just network propagation. Other household traffic may already be active during the nominal idle phase.

Follow the loaded sample plan

  1. The worker records its download-phase start and end. UI polling alone is not authoritative phase evidence.
  2. A separate sampler makes at most five sequential HTTP attempts during download, waiting 150 ms between attempts.
  3. Each accepted request must return HTTP 2xx, have finite nonnegative timing, and finish within its request budget.
  4. Both dispatch and completion must fall inside the worker's download window. Cross-context alignment uses performance.timeOrigin + performance.now().
  5. Only five accepted probes, no exclusions and a valid idle baseline allow a mean delta. Otherwise the loaded result is unavailable.

This sampler does not measure a separate upload-loaded series or establish that every observed connection was saturated. Download and upload throughput phases do not make the loaded metric bidirectional.

Why new grades are withheld

A grade threshold needs a justified definition, reproducible inputs and validation for the use claimed. Those requirements are not supplied by assigning a letter to a small sample. New snapshots therefore carry a measured delta or an explicit unavailable state, not A–F.

A grade retained in old history or a shared link is labeled legacy/unverified. It cannot establish a router defect, an ISP-wide condition or equivalence with another tool's grading system.

The calculation is a mean, not P90

Delta (ms) = max(0, round((r1 + r2 + r3 + r4 + r5) / 5 − idle estimate)).

For an illustrative calculation, five loaded RTTs of 20, 22, 24, 26 and 28 ms have a mean of 24 ms. With a valid 10 ms baseline, the displayed delta is +14 ms. These numbers are an example, not a connection measurement or research dataset.

An arithmetic mean summarizes these five values; it can conceal their spread and remains sensitive to unusual values. No accepted slow sample is silently removed as an outlier. The zero floor and rounding can also conceal a small difference. This calculation is not a percentile, distribution, confidence interval or prediction of a gaming session.

Validity rules, not anti-gaming guarantees

HTTP errors, network failures, timeouts, aborts, exceptions, invalid timing and stale callbacks cannot become successful latency samples. Attempts and exclusions are retained. Run-wide limits prevent UI updates from starting a new budget.

The limits are 2,000 ms per request, 6,000 ms for loaded sampling and 20,000 ms for the worker idle sequence. They bound waiting and may exclude slow connections; they are provisional engineering budgets, not latency-quality standards. A timed-out request has no successful RTT.

Random query parameters do not prove that traffic cannot be recognized or prioritized. This method does not establish rotating independent servers, protocol camouflage or immunity to ISP traffic classification.

Compare like-for-like evidence

Keep the contract version, browser, device, connection method, time, endpoint if available, and sample evidence. The timing source changed to full HTTP completion from the earlier Resource Timing substitution; even with the estimator retained, old and new runs are not automatically comparable.

New JSON snapshots retain structured inputs and statuses; CSV includes measurement metadata. Shared parameters and local history are user-controlled, not authenticated evidence. Do not compare a number from this download-only mean with another tool's percentile or upload-loaded grade as if their methods matched.

Check a saved result before comparing deltas

After a completed run, choose Export JSON and open the file locally in a text editor. Review network labels and timestamps before sharing it. These field paths describe the current snapshot format, not a promise that older history or every shared link contains them. Missing evidence is not a pass, and an unavailable value is not zero.

  1. Identify the format. Check schemaVersion and measurementStatus. A current evidence-bearing snapshot uses schema version 2. A legacy record or invalid measurement object must not be relabelled as a current successful run.
  2. Identify the method. Check measurement.contractVersion and the timing basis. For this guide the contract is http-rtt-v1, using full HTTP completion timing. A metric from another tool may have a different definition.
  3. Check whether the loaded value exists. Read measurement.loaded.valueStatus before reading a number. Only measured identifies a measured loaded delta in this contract. A timeout, incomplete series or invalid baseline is not a measured zero.
  4. Inspect the accepted inputs and exclusions. Review measurement.loaded.samplesMs, measurement.loaded.attempted and measurement.loaded.failures. A complete loaded plan needs five accepted probes and no exclusions; do not delete a slow sample or turn a failed request into a timing.
  5. Retain phase and baseline evidence. The structured JSON includes measurement.loaded.spansMs and measurement.loaded.windowMs for a complete series, together with idle-series evidence. The application checks that probes fall within its recorded download window. A list of timings alone does not prove phase membership or that the link was saturated.
  6. Compare the same quantity. Keep measurement.loaded.baselineMs, measurement.loaded.meanMs and measurement.loaded.deltaMs together with the conditions of the run. A lower delta with a changed endpoint or a lower transfer rate does not by itself prove a router setting helped.

If you only have CSV, retain its measurement-evidence status, sampling status, attempts, durations and exclusions. CSV is not a complete copy of every nested phase field. Preserve the JSON when a detailed review is needed, and do not reconstruct absent fields from a screenshot or an old letter grade.

Before changing queue-management settings: save the router configuration and confirm you can restore it. Follow documentation for the actual device and firmware, keep required security controls, change one setting at a time, and compare useful throughput as well as responsiveness. OpenWrt's SQM guidance documents CPU and offloading constraints; its device examples are not measurements of your router or guarantees for this test.

Use the methodology and validity rules when a field is unavailable. There is no universal pass/fail threshold or new letter grade in this guide, and these inspection steps are not a diagnosis of an ISP or router fault.

Turn the observation into a controlled check

Repeat with the same device and endpoint where practical. Compare a wired baseline with the problem Wi-Fi location as separate conditions, and retain unsuccessful runs. Check the actual game or call too: it may use another path.

A repeatable increase during traffic is a reason to investigate queueing, not proof that a particular router is faulty. OpenWrt's SQM documentation describes queue-management options and CPU limits. That guidance does not promise an immediate grade improvement or compatibility with every device.

Do not bypass required security controls or replace hardware based only on a letter from an old result. Keep changes reversible and compare responsiveness as well as useful throughput.

Run a diagnostic and retain the conditions and any errors. A result is an observation, not a provider verdict.