Speed is the primary measure by which broadband connections are sold, so clearly it's important to measure it. We offer a variety of different mechanisms to measure speed.
- Our standard speedtest, used on Whiteboxes, CPE and mobile apps.
- An alternative speedtest that is ultra lightweight in terms of bandwidth usage and time.
- A WebSockets and XHR based speedtest for use in web browsers.
- This speedtest can take advantage of specific Broadcom and Qualcomm hardware to measure extremely high speeds.
Supported clients: Whiteboxes, Routers, Android, iOS
Measures the download and upload speed of the broadband connection in bits per second. The transfer is conducted over one or more concurrent HTTP connections (using the GET verb of download and the POST verb for uploads).
In the download speed test the client will fetch a portion of an infinitely sized binary (non-zero, randomly generated) payload hosted on an HTTP server on the target test server. The content is discarded as soon as it is received.
In the upload test the client will generate the payload itself (using /dev/urandom as a non-blocking source of random content) to send to the server. The measure of throughput may be optionally carried out on the server side (the receiver) in the upload test.
The speed tests (both download and upload) operate for either a fixed-duration (specified in seconds) or a fixed-volume (specified in MB). Where possible, a fixed-duration test is preferred as it will cater well for all broadband access speeds. However, a fixed-volume test may be necessary where predictability of bandwidth usage is desired.
Four separate variations of the test are supported:
- Single TCP connection download speed test
- Multiple TCP connection download speed test
- Single TCP connection upload speed test
- Multiple TCP connection upload speed test
For multiple TCP connection tests we typically recommend that three concurrent connections are used. In some cases (e.g. where the round-trip time between client and server is very high) it may be necessary to increase this.
Factors such as TCP slow start are accounted for through the use of a “warm-up” period. This period begins as soon as the test starts and seeks to establish that the throughput has reached stable rate before starting the real test (which will continue over the same TCP connection(s)). It is important to note that the data transferred in the warm-up period is excluded from the main test results, but it is still recorded separately as a supplementary metric.
The speed test client will record the throughput, bytes transferred and time taken at the end of the test. It may also record these values at multiple intervals during the test. This is commonly used to help characterise the difference between 'burst' and 'sustained' throughput (where transfer speeds may be inflated at the start of a TCP connection).
Supported clients: Whiteboxes, Routers
This test measures the instantaneous capacity of the link using a small number of UDP packets. The test supports both downstream and upstream measurements, conducted independently.
In the downstream mode, the test client handshakes with the test server over TCP, requesting a fixed number of packets to be transmitted back to the client. The client specifies the transmission rate, number of packets and packet size in this handshake. The client records the arrival times of each of the resulting packets returns to it.
In the upstream mode, the client again handshakes with the test server, this time informing it of the characteristics of the stream it is about to transmit. The client then transmits the stream to the server, and the server locally records the arrival times of each packet. At the conclusion of this stream, the client asks the server for its summary of the arrival time of each packet.
With this resulting set of arrival times, the test client calculates the throughput achieved. This throughput may be divided into multiple windows, and an average taken across those, in order to smooth out buffering behaviour.
This test uses approximately 99% less data than the TCP speed test and completes in a fraction of the time (100 milliseconds versus 10 seconds). The lightweight capacity test achieves results are within 1% deviation from the existing speed test results on fixed-line connections tested on average.
Supported clients: Web
Measures the download and upload speed of the broadband connection in bits per second. The transfer is conducted over one or more concurrent TCP connections. WebSockets and HTTP (using the Fetch API) are used via HTML5 APIs as the transport for all measurement traffic. This requires the web browser to support HTML5.
In the download speed test the client will repeatedly fetch chunks of data from the target test server. The content is discarded as soon as it is received. The client will determine from the user agent which is the best transport protocol to use; some browsers perform better with WebSockets and others perform better using the Fetch API. In all cases, speeds of at least 1Gbps are attainable on modern hardware, except on Mac OS X.
In the upload test the client will generate the payload itself to send to the server. Similarly, the client will repeatedly upload chunks of this data to the target test server, which will immediately discard the content.
The speed tests (both download and upload) operate for a fixed-duration specified in seconds. A maximum limit on transfer volume may be imposed if data volumes are of concern.
Both the download and upload tests use eight concurrent TCP connections by default. The size of the chunk to transfer will vary between 16KB and 1MB, and will be determined automatically during the warm-up phase of the test.
Factors such as TCP slow start are accounted for using a "warm-up" period. This period begins as soon as the test starts and seeks to remove the impact of TCP slow start from the results and serves to determine the number of TCP connections to be used for the remainder of the test. It is important to note that the data transferred in the warm-up period is excluded from the main test results.
The speed test client will record the throughput, bytes transferred and time taken at the end of the test.
Supported clients: Broadcom-based Routers
The hardware-accelerated UDP speed test use hardware-specific APIs provided by Broadcom in order to achieve measurements of 1Gbps (and beyond) on low-end hardware. The measurement traffic is not directly handled by the main CPU, and instead uses a separate network co-processor. The Broadcom "speed service" API allows the SamKnows measurement client to issue instructions to the network co-processor.
For a download test, the hardware-accelerated UDP speed test client issues a download test request to the SamKnows test server over TCP, requesting that the server begin transmitting UDP test traffic back to the client. The client then issues an API call to the Broadcom network co-processor requesting that it begin counting the amount of packets received. The speed test client then instructs the server (via the TCP control channel) to ramp up the sending rate rapidly until a stable rate is achieved. The instantaneous throughput is determined by the client polling the Broadcom API to ask for the amount of packets received multiplied by the packet size. At this point the client continues its measurement for five seconds, after which another call is made to the Broadcom API to stop counting incoming packets.
For an upload test, the hardware-accelerated UDP speed test client issues a notification to the test server over TCP, informing it that transmission of UDP test traffic is about to commence. The client then issues an API call to the embedded Broadcom network co-processor requesting that transmission of UDP packets to the specified destination IP address begin. Packets are transmitted at full line rate immediately and for the entire duration of the test. The packet size can be configured, and is 1400 bytes by default. After five seconds the client issues a follow up API call to the embedded Broadcom network co-processor requesting that UDP packet transmission stop. The client then interacts with the test server again over TCP to retrieve the received rate from the server's perspective.