How we measure your connection

Automatic server selection

Your browser checks the configured regions when you open the page or refresh the server list. It warms each connection, then compares the median of three small HTTP latency probes. At least two probes must succeed. Automatic mode chooses the reachable region with the lowest median. Your selection stays in place for subsequent tests. Each test measures latency again, and Automatic mode can try another available region if the selected server stops responding before speed measurements begin. You can also select a region yourself.

Download and upload

The test transfers randomly generated data directly between your browser and the selected regional server. Multiple parallel requests adjust their payloads toward a 600 ms request duration. Throughput is the total payload received over elapsed wall-clock time, including request overhead. Uploads count only after the server acknowledges the entire body. The live headline and graph display a one-second rolling average of measurements taken every 250 ms, with brief visual transitions between updates. Reduced-motion preferences disable these transitions. The final headline is sustained average payload throughput across the transfer phase; animation does not change measurements, percentiles or saved results. Aggregate P90 uses original intervals after the first second of calibration. Per-request P90 describes individual streams and is shown separately.

Latency and jitter

Idle latency is the median of ten HTTP round trips after connection warm-up. Jitter is the mean absolute difference between consecutive idle samples. During downloads and uploads, extra small requests measure latency under load. These are application-level HTTP measurements, including browser scheduling and server response time, rather than ICMP pings. A dash means no valid measurement is available.

Interpreting your results

This measures the path to the selected datacenter, not every destination on the internet or a guaranteed ISP line rate. Wi-Fi, VPNs, your device, other traffic, browser connection limits and server capacity can affect the results. Keep the tab visible and pause other large transfers for a more consistent comparison. Packet loss is measured separately over WebRTC/UDP when your browser and the selected region support it.

Packet loss

During each transfer and again after the HTTP phases, your browser sends 1,000 random, 64-byte messages over an unordered WebRTC data channel with retransmissions disabled. The selected region echoes each message. Unique replies count as received; replies missing after a three-second grace window count as lost. We also record duplicate replies, reordering and round-trip times. This is round-trip application-message loss over UDP, not one-way IP packet loss. A blocked or failed UDP test is unavailable, never zero percent loss. A loaded UDP result is retained only when the HTTP transfer remained active throughout the entire UDP measurement. Short transfers may not provide enough overlap. HTTP results remain available.

Responsiveness and quality

Loaded jitter is calculated separately for each transfer direction. The Measurements view also shows minimum, maximum, mean, median, P25, P75 and P95 latency, box plots and individual samples. Load increase (a bufferbloat indicator) is calculated separately for download and upload as the loaded median minus the idle median, floored at zero. Remote desktop, streaming and video-call ratings use OneMind Services scoring rules. Streaming and video calls weight throughput, response time, latency under load, jitter and packet delivery for each activity. Video-call scores are also limited by throughput in both directions: a 3 Mbps uplink and 5 Mbps downlink reach the top of the capacity scale. Loaded UDP loss contributes when measured. These thresholds are product heuristics, not service requirements. Scores range from 0 to 100 and remain incomplete when a required measurement is unavailable. These ratings are estimates for the selected datacenter path, not guarantees of performance in a particular service.

Remote desktop (RDP)

The RDP estimate focuses on typing, clicking and scrolling during typical office work on one 1080p remote desktop. It uses the worst idle or loaded median latency, worst idle or loaded jitter, worst measured UDP message loss, and throughput in both directions. The weakest factor limits the score, so high throughput cannot hide input delay or stutter. Our bandwidth scale reaches its maximum at 5 Mbps download and 1 Mbps upload; the upload allowance is a OneMind Services headroom choice. Multiple monitors, higher resolutions, video and file transfers can need more bandwidth. At least two latency samples are required in each phase, along with throughput and the final UDP measurement. This is a network estimate, not an actual RDP session test. Choose a region near your remote host, and account for its load, display settings and VPN or gateway route when interpreting the rating.

Reference: Microsoft’s Remote Desktop network guidance. The rating thresholds are our own estimates.

Time and data limits

Standard tests begin with an eight-second window per direction and may extend to fifteen seconds. Extension depends on request duration, sample count and throughput stability. Requests aim for 600 ms and use payloads up to 32 MiB or the server’s lower limit. Quick tests use shorter windows and up to 512 MiB per direction. Extended tests use a thirty-second window and twice the Standard data budget. All modes respect operator limits. Standard allows up to 16 GiB per direction and Extended up to 32 GiB per direction; actual usage is shown during the test. Transfers still in progress at the maximum duration are cancelled. Only acknowledged uploads count toward throughput; a cancelled upload may have sent additional bytes, within the reserved data budget. HTTP, UDP and network overhead are additional. No bandwidth test starts until you select Start test.

Measurement confidence and network diagnostics

Consistent results contain at least sixteen aggregate intervals after calibration, with a relative interquartile range of at most 20% and stable recent windows. Variable results show greater spread or drift. Limited results have too few sustained samples or reach the data budget early. These labels are quality indicators, not statistical confidence intervals. Network diagnostics show the address observed by the API, an optional locally resolved ASN and separately configured IPv4 reachability. Browser timing may expose DNS, TCP, TLS, request-to-first-byte, response duration and HTTP protocol. Reused or unreported connection timings remain unavailable. Datacenter maps use configured coordinates, not inferred customer locations.

Data handling and privacy

There is no analytics SDK. Completed results are stored by this application. The last ten summaries are kept in your browser when local storage is available. Measurement uploads contain generated test bytes. Test servers necessarily see your network address to serve requests; the API returns it to this browser for live network diagnostics and uses it temporarily for UDP capacity limits. It is not sent to an external lookup service. API logs record request IDs, routes, status codes, duration and byte counts. Random session and test IDs help operators connect related requests when diagnosing a problem. The session ID lasts for this browser tab session and is not an account identity or a device fingerprint. API logs exclude client addresses, request payloads and WebRTC negotiation data. Infrastructure operators may maintain separate access logs.