Test Explanation

If the hotel concierge answer’s your question “how long does it take to get to the airport?” with “the road to the airport is 300 cars per minute”, you would be none the wiser. Stating the rate of cars on a road does not define any measure of time. The user experience is only defined by time, i.e. 'faster' is better than 'slower'. For example, at 300 cars per minute the time to the airport will be slower if the distance is 100 miles versus faster if it's 20 miles. Our expectation of bandwidth is that a higher bandwidth value is faster than a lower bandwidth value. This is simply not true, latency is the true speed end-to-end because it defines the time. The rate only defines the capacity of the connection, e.g. the number of users that can share the connection.

This bandwidth test is designed to report three important measures about the connection under test. First, the true bandwidth of a connection and not just what the ISP claims. Most tests report the bandwidth attained even if it is just 10% of the test. Naturally many ISPs promote such glossy tests for obvious reasons. Second, the time of data delivery. This measure defines if the true user experience is correct for the time to destination. This measures if the user experience is working to time. Third, consistency of the data throughput during the test. This exposes bad speed tests that always report good results by excluding data that is underperforming.

To run this test enter either the Mbps setting you are expecting or alternatively enter a Percentile setting for inclusion. As an example, entering 100Mbps will reveal what percentage of the packets managed to achieve 100Mbps. Entering 80% will reveal the bandwidth for the best 80% of the data. Learn More