Every time an advertisement for an Internet Service provider appears in the media, the focus is to aggressively extol the virtues of ‘so many' megabits per second. These advertisements are designed to increase sales, playing to the Internet users obsession with ‘speed'. The end result is that almost all users are brainwashed into thinking that faster speeds make applications perform faster and that their Internet experience will dramatically improve. Sadly nothing can be further from the truth.
There are many myths on Internet speed and performance, here are some common ones.
1. I have a 10Mbps connection so I can browse at that ‘speed'
False, a rating of ‘x' Mbps is not a speed but a max capacity rate. The maximum throughput of a connection is governed by
a. The minimum bandwidth of the connection end-to-end,
b. The TCP window size and latency of the connection end-to-end,
c. Contention delays,
whichever is the smallest. The so called ‘speed' will never be consistent because each website or web service accessed is unlikely to be on the same network path or even have the same latency.
2. If I increase my Internet connection speed from 5Mbps to 50Mbps my Internet browsing experience will be ten times faster.
False, increasing a connection's rate expands its capacity but not necessarily its throughput (what most people call speed). This means that you can do more things at the same time but not any faster. In fact, the faster the rate the less likely the increased throughput can be achieved because the connection latency needed to support that rate gets smaller.
3. My 10Mbps Internet speed will be consistent no matter where I browse
False, overall browser performance (TCP) will be dictated by the TCP Window size, the distance between the client computer and the destination and/or the connection rate, whichever results in the lowest value. As destination servers are all over the world no two web services or indeed no two PC clients are ever likely to perform at the same throughput (speed).
4. Speed is more important than quality because data quality does not affect my connection performance.
False, the quality of data flow is more important to application performance (and the user experience) than speed. Poor data quality leads to data loss, duplicates and retransmissions all of which dramatically impact throughput (Speed) and application performance.
5. Internet speed testers measure connections speed.
False, nearly all internet speed testing applications do not measure speed at all but instead measure capacity. That is not specifically a problem except the person running the test is generally not aware of the difference and accepts the result as the connection speed that will be achieved. Unfortunately a capacity measure just defines how much data the connection can hold, not the throughput performance of the connection. Only the throughput governs the user application experience with very few exceptions. Furthermore most Internet test applications do not measure capacity accurately which results in the testing user being misinformed further.
[ White Paper - Understanding Internet Speed Test Results - The problem is not in the measurement, it is in understanding the test results as they relate to the application problem being experienced (PDF) ]
6. Some packet loss is acceptable if it is just a few packets
False. This is a bit like saying plane crashes are okay so long as the plane is small. Packet loss, (aka data loss) should never occur, period. There is no acceptable reason for data loss and the penalties involved can and will cause applications to fail eventually. If data packets are getting dropped it is because the network is poorly structured.
7. My Internet connection is 100Mbps so there is plenty of Internet capacity for my business.
False. While 100 megabits per second sounds like a lot, it is important to realize that the capacity of a connection is dictated by the product of the latency and the bandwidth. This means that 100 megabits per second on a short 2ms connection will be saturated to its capacity with just 25Kbytes of data. This is smaller than just one small Jpeg image on any web page and most web pages have many such images plus all sorts of other data objects including text strings. To demonstrate this point further, lower connection bandwidths for example 5 or 10 megabits per second can be saturated with just one or two packets.
8. If I increase my TCP window size I will get a faster speed.
False, increasing the TCP window will not guarantee faster throughput, in fact for item 7 above it is quite likely to have the opposite effect. Increasing the TCP window scale factor is only a request which has to be approved. In reality Window scale requests are more likely to be declined for a variety of different reasons. Also to avoid quality problems the Window size needs to be a different value for every connection established and if the value set is greater than what is needed then data loss becomes a higher risk. Increasing scale also means more unacknowledged data end-to-end which dramatically increases data loss recovery time if quality problems do occur. Such problems can easily drop a 20Mbps connection by a factor of ten to less than 2Mbps.
There are many myths that surround the thorny subject of Internet speed, the eight above are just a few common misnomers. The core of the emotional pain is that the majority of Internet users expect ‘the speed they buy is actually what they will achieve'. Unfortunately that is the biggest myth of all, because for most Internet users there is no such thing as speed. There is only ‘throughput'. The ‘x' Mbps rating of a connection is not a speed but a capacity rate. The throughput (speed) of a connection is dependent on many factors the biggest of which is latency and obviously contention.
If you also consider that applications have evolved from the traditional wired platforms running batch applications, such as email and browser, to social and media rich applications such as TV, video, music and voice on mobile wireless platforms, it is hardly surprising that contention has grown and organizations such as Akamai report that by the end of 2011 connection ‘speeds' dropped by 14% last year.
About the Author
Julian Palmer has spent more than 30 years in technology specialising in operation management and service delivery. In his current role of Chief Technology Officer of Visualware, Julian has leveraged his experience and detailed knowledge of application data flow to evolve solutions for measuring and reporting network quality.
Founded in January of 2001, Visualware, Inc. is a leading creator of solutions to manage and report the true customer and end-user Web experience.
Visualware’s Enterprise solutions include a suite of products and OEM technologies that enable any business or organization to view, report and troubleshoot a customer's actual transaction response time anywhere in the world -- as it happens in real time. Learn more about Visualware