Short answerDelay is the delivery time, loss is the absence of the expected message. Check them separately and repeat the measurement along the cable, maintaining the same conditions.

What symptoms should you check for?

The voice breaks into fragments, game actions roll back, and the video call briefly freezes. Such symptoms are compatible with losses, but do not prove them: an overloaded computer, application and its server give similar behavior.

A normal HTTP request may wait for re-delivery at a lower level. Therefore, the failed HTTP probe count cannot simply be renamed "percentage of lost packets." This check uses a separate WebRTC channel without re-delivering messages.

Packet loss test

Free

Loading the check...

How reconciliation works

The browser sends numbered messages. The server stores the numbers of received messages and sends an echo. At the end, the client receives the server log via HTTP and compares three lists: sent, received by the server, returned to the browser.

“Losses up” are calculated based on the number of messages sent. “Echo loss” is based on the number of messages that the server actually received. If you divide both indicators by one initial value, the directions are easy to confuse. The report stores quantities so that the result can be verified.

This is an application-based measurement via a browser. A WebRTC message and an IP packet are not interchangeable units, and application load can also affect delivery. The service does not present this result as a laboratory analysis of the line.

If the connection does not open

WebRTC failure does not mean 100% loss. Possible UDP restrictions, browser policy, VPN, corporate network, or measurement node configuration error. In this case, the test shows a connection error, and not zero Internet quality.

Open HTTP stability check, try again without VPN if your network allows it, and try a different connection. Don't disable corporate protections for the sake of a test; pass the result to the administrator.

What to do after discovering losses

  1. Repeat two or three short runs without changing the conditions. A single short measurement has a large random error.
  2. Connect via cable and turn off Wi-Fi on the computer you are checking.
  3. Check another device on the same network. If the problem remains only with the first one, narrow the search to its adapter and programs.
  4. Compare a quiet network and a moment of active transmission. Useful depending on the load bufferbloat test.
  5. Submit a support log with time, conditions and number of messages.

Can 0% be considered a guarantee?

No. Zero means there are no undelivered test messages in the selected interval to a specific node. Less frequent failures, different routes, and different message sizes remain unobservable. A good result is useful, but its scope must be preserved along with the number.

Sources and methodology

Calcomera editorial teamTests, explanations and open limitations of the method. About the editors