Latency, loss and jitter.

Latency, packet loss and jitter affect everything you do on the internet. If these fare badly, then every other test will fare badly. So they are critical to measure.

Back to top

Latency and packet loss (UDP)

Supported clients: Whiteboxes, Routers

Measures the round trip time of small UDP packets between the router and a target test server. Each packet consists of an 8-byte sequence number and an 8-byte timestamp. If a packet is not received back within two seconds of sending, it is treated as lost. The test records the number of packets sent each hour, the average round trip time of these and the total number of packets lost. The test will use the 99th percentile when calculating the summarised minimum, maximum and average results on the router.

The test operates continuously in the background. It is configured to randomly distribute the sending of the echo requests over a fixed interval, reporting the summarised results once the interval has elapsed.

Typically 2000 samples are taken per hour, distributed throughout the hour. If the line is busy then fewer samples will be taken. A higher sampling rate may be used if desired.

Back to top

Contiguous packet loss / disconnections (UDP)

Supported clients: Whiteboxes, Routers

This test is an optional extension to the UDP Latency/Loss test. It records instances when two or more consecutive packets are lost to the same test server. Alongside each event we record the timestamp, the number of packets lost and the duration of the event.

By executing the test against multiple diverse servers, a user can begin to observe server outages (when multiple probes see disconnection events to the same server simultaneously) and disconnections of the user's home connection (when a single probe loses connectivity to all servers simultaneously).

Typically, this test is accompanied by a significant increase in the sampling frequency of the UDP Latency/Loss client to ~2000 packets per hour (providing a resolution of 2-4 seconds for disconnection events).

Back to top

Latency, jitter and packet loss (UDP)

Supported clients: Whiteboxes, Routers, Android, iOS

This test uses a fixed-rate stream of UDP traffic, running between client and test node. A bi-directional 64kbps stream is used with the same characteristics and properties (i.e. packet sizes, delays, bitrate) as the G.711 codec.

The client initiates the connection, thus overcoming NAT issues, and informs the server of the rate and characteristics that it would like to receive the return stream with.

The standard configuration uses 500 packets upstream and 500 packets downstream.

The client records the number of packets it sent and received (thus providing a loss rate), and the jitter observed for packets it received from the server. The server does the same, but with the reverse traffic flow, thus providing bi-directional loss and jitter.

Jitter is calculated using the PDV approach described in section 4.2 of RFC5481. The 99th percentile will be recorded and used in all calculations when deriving the PDV.

Back to top

Latency (HTML5)

Supported clients: Web

Measures the round-trip time of a series of small packets between the user's workstation and the target test server. WebSockets are again used as the transport for these measurements.

At startup, the client's web browser will transmit a series of small 8-byte echo packets (containing a sequence number and a timestamp). The server will echo these packets back to the client. The client will then use the difference between the current timestamp and the timestamp contained within the packet to estimate latency. An average across all packets received is used to determine the average round-trip time.

The round-trip time recorded in microseconds, and the volume of packets transmitted is also recorded too.

Back to top

Latency and packet loss (ICMP)

Supported clients: Whiteboxes, Routers

This test measures the mean round trip time (RTT) of ICMP echo requests in microseconds from the Whitebox to a target test node. The client sends 5 ICMP echo requests of 56 bytes to the target test node waiting up to three seconds for a response to each. Packets that are not received in response are treated as lost. The minimum, maximum and standard deviation of successful results are also submitted.