There is no perfect way to test the speed of a network, but the most tried and true has been speedtest.net by Ookla and speedof.me which does HTML5 speed tests. To understand why enterprise networks would make this test better you need to understand what is going on within the speed test.
Ping: This test sends HTTP requests to the selected Server, and measures the time it takes to get a response.
Download: As described by Speedtest Support and other engineers is that your computer downloads small binary files from the web server to the client, then they measure that download to estimate the connection speed. Based on that result they choose how much data to download for the real test. The goal is to make sure the right amount of data is chosen that can be downloaded within 10 seconds, ensuring that you get enough information sent and received for an accurate result but not have it take a long amount of time to do the actual test. Speedtest.net prevents caches from throwing off results by appending random strings to each download.
Once the download is started it uses four HTTP threads to saturate the connection and get accurate measurements. Throughput samples are received at up to 30 times per second. The samples are than aggregated into 20 slices (each being 5% of the samples). The fastest 10% and the slowest 30% of the slices are then discarded. The remaining slices are then averaged together to determine the final result. Since the data is measured by transporting over HTTP (via Flash) there are factors that affect speed: potential protocol overhead, buffering due to the many layers between the application and the raw data transfer, and throughput bursting due to primarily CPU usage. Those factors lead Ookla to drop the top 10% and bottom 10% of their slices as outliers. Additionally because the test is shorter, the ramp-up period can take a significant part of the beginning of the test, leading them to drop another 20% of the bottom result slices. So if you had 10% speeds at 300Mbps, and the slowest at 210Mbps during the ramp up that data would be chopped and you’re speed would show the Medium of 255Mbps which is 60% of the tested data rates tested at.
Upload: Small amount of random data is generated in the client and sent to the web server to estimate the connection speed, based on that result and appropriately sized chunk of randomly generated data is selected for upload. The upload test then performed in chunks of uniform size, and pushed to the server-side script via POST. Ookla uses four HTTP threads here as well to saturate the connection. Chunks are sorted by speed, and the fastest half is averaged to eliminate anomalies and determine the results.
There are multiple factors that cause results with these speed tests, if you’re using a 3rd party Router you’ve typically bridged the all-in-one device, or if you only replaced wireless than you took out the poor wireless provided by the all-in-one devices. The thing is, speed test sends data from the client (computer, mobile phone etc) to the server you choose (L.A, Ohio, where-ever). All the results are measurements of data from the client device whether wired or wireless sending and receiving data by going through an access point, and router in the network. If the router doesn’t support the speeds than your measurement of data will be drastically different than if you had a Enterprise router in the system. Same goes for the wireless, if you had a router in the system that supported the speeds, but the wireless access point didn’t you’d get the results from the weakest link in the system. So when someone is reporting that they are getting better speeds it is because what they were using before just didn’t cut it. I had the same personal experience when I had a Linksys DIR-655, and an Apple Airport Express, they were both limited to getting between 30MB/s and 65MB/s(these speeds dropped when using wireless). Once I upgraded to Enterprise grade router I could finally see and get the speeds I was paying for at 100MB/s.
Basically, it boils down to the weakest link in the chain.
Jason Gibson is a computer enthusiast and network security and installation professional. Read Gibson’s explanation of VLANs: What They Do and Why They Matter.
