Read validity before the number
A displayed result is useful only in the context of its method and warnings. VelocityVerify estimates throughput and HTTP request timing from a browser. It is not an ICMP or UDP probe, a game-server measurement, or an end-to-end packet-loss test. New letter grades are withheld. An incomplete timing run must not become a valid latency claim simply because throughput was displayed.
Keep the units and measurements separate
Download and upload are displayed in megabits per second, or Mbps. A file-transfer application may show megabytes per second, or MB/s: multiply MB/s by eight to compare the units. That conversion does not remove protocol overhead, server limits, or disk and application effects. A faster throughput result is not a prediction of every transfer’s completion time.
HTTP timing is a path-and-browser estimate
The timing reflects the request method, browser scheduling, connection behavior, server work, and intervening network. It is not a direct measurement of the access line alone. Keep idle timing distinct from timing observed during the download window. This implementation does not provide a separate upload-loaded latency series. Read the methodology for sample rules and exclusions.
Timing variation is not a packet-loss percentage
The displayed HTTP variation describes differences in accepted timing samples, as documented in the method. It is not a universal definition of jitter for every protocol, and it cannot establish end-to-end packet loss. A valid zero is different from unavailable evidence. N/A means unavailable or invalid, not a successful zero-delay measurement.
Compare the symptom under repeatable conditions
Record device, interface, task, destination, time, other traffic, and warnings. Repeat wired and wireless conditions on the same device when possible. Keep unsuccessful runs. If only one application is slow, inspect its own statistics and status too. Share a dated log with support rather than inferring one cause from a quality band or the best result.
Read an illustrative result without inventing missing evidence
Invented teaching example, not a measured VelocityVerify run. Suppose a saved note shows 80 Mbps download, 12 Mbps upload and N/A for timing, with a timing-validity warning. These values do not describe a tested provider or a real user's connection.
- 80 Mbps download
- A throughput estimate for that run's download direction, not a promised application transfer rate. Dividing by eight gives 10 MB/s before overhead and other constraints; this is unit conversion, not a predicted file-download result.
- 12 Mbps upload
- A separate direction. It does not validate the unavailable timing measurements or establish how a call behaved during an upload.
- N/A and a validity warning
- Keep the timing unavailable. Do not substitute 0 ms, attach a letter grade, calculate a timing increase, or claim packet loss from this result.
- Keep the warning alongside the two throughput estimates, plus the device, connection type, time and endpoint if available.
- Repeat under comparable conditions and retain failed as well as successful runs. A later valid timing result is a separate observation; it does not repair the earlier sample.
- If the complaint is a broken call, inspect that application's own quality information. A browser throughput run alone cannot confirm the call's cause.
Read the methodology for the implemented validity rules. For planning, take the measured directions and their limits into your task record rather than converting them into a universal “good” score.