This knowledge base article is being provided to help explain what various speed test results mean, and how we react to reports of those speed tests at FlashByte.
When you bring up a website, like speedtest.net or a similar site that is running inside a flash program in your browser and you run a speed test, something is being tested, but it is not what the maximum throughput possible on your FlashByte connection is.
That kind of test is limited by several factors, and will almost never be an indication of the maximum throughput possible on your link. It should be used as an indicator of “at least” what you can get. What I mean by that is, that if you see a result on a speed test, your link certainly was capable of that speed, but it might also be capable of several times that speed, possibly even up to 10 times the speeds you are seeing on the test.
Other devices using the link, loads on your computer, issues between our network and the network being tested, along with hundreds of other things can cause those tests to be slower than what is possible. We do not rely on those tests to measure much of anything, and instead will be much more interested in what is actually happening on your link when you try to do things other than running tests.
Almost Everything Uses Multiple Streams
Almost everything you do on the Internet uses multiple threads/streams. When you are playing a movie on a service like Hulu or Netflix the program will open many data streams, when you are watching one program on one device, the device will actually be downloading content on usually 4 or 5 different data connections at the same time. So when we say that single threaded tests do not show what you will see, we mean it. Even if you are using one device and watching one program you can often be downloading at 4 or 5 times the speed you would see on a single threaded test like speedtest.net. We often see real world usage getting download speeds of 10 times what can be seen on a speed test. Those tests are just not an accurate measure of what you will get while actually using your FlashByte connection.
When you open a web page every image on the page will usually open a seperate data stream. On the network level when you are surfing the web there will usually be 10 or 15 connections open every time you click on a link and open another page. The only way to really get a meaningful result about what you are using on our network is to actually use it for what you want to do, and then watch the traffic levels at your router to see what is being tranfered, or use an advanced multi threaded test with different packet sizes and conditions to replicate real world usage.
But that doesn’t make sense! Why is that true? I used to have [insert name of Internet delivered over some other network here] and I saw the maximum speed I could get on that test site!
FlashByte uses a variety of methods to deliver service to places that cannot be reached with traditional link types. One of these methods is to deliver content simultaneously across multiple physical paths. This process is often invisible to our customers even if they are using advanced network diagnosis tools. In normal use of a website, your browser might open 10 different links to various content and images on a website, and in another scenario several different devices might be accessing the Internet at the same time on your network. In these situations each of those devices might be opening a stream to the Internet that is taking a different path across different devices and connections in order to download the content (even though the IP address path may appear to be the same). Since there are many paths out to the Internet over your connection with FlashByte, when you run a single threaded test like speedtest.net, it is only measuring the available bandwidth across one of those paths at any given time. Especially when the network is busy, the speed across a particular path for the length of a speed test might be low.
Our network is constantly balancing the real world use of the various content we are delivering, and your content will be directed across paths best suited for what it is doing. A speed test is a particularly useless piece of data, and it is generally not prioritized by our network protocols very highly. If you were to set up a router with multiple devices and measure your throughput at the device on the interface serving your network doing actual tasks or using real services on the Internet, you would see that far more bandwidth can be pushed through to your network than you can see in a single speed test result. We have professional speed test tools that open multiple threads and test across up to 20 threads at a time, and we will often see 10 or more times the speed you will ever see on a single threaded test.
So that means I have 10 times the speed I see on my test?
No that means that the test you are using is not really an indicator of anything other than what the minimum speed you can get on a single thread is. There is no way for you to measure your speed on our network with that kind of test, you would need to monitor speeds at your router and actually use the Internet for various things at the same time from different devices in order to see your maximum possible throughput, running bursty tests on single threads is never going to show the maximum, unless you happen to be hitting your package cap in a single thread. Which just means your package is what is limiting your speed, we often will have 10 or 20 times the capacity of your package physically possible across the equipment at your location.
But I get results that equal my package sometimes and now I am not so it must be slower now, something is wrong.
This is not the case. When you are getting your full package speed on a single threaded speed test that just means that at that moment you have your full package cap available over a single thread. There is probably 10-15 times the package cap available to your location when you are seeing speed tests like that. When the network gets busier, or whatever else changes so that you are seeing less speed on a single thread, you can often still hit your package cap when you are using the Internet to actually do things. Since you are being limited by your package cap in both situations, your connection is not slower, you are just seeing slower test results because what you are testing is not a representation of what you can actually do on your link.
But I only care about single threaded tests to single hosts!
Our network was not built for you, sorry. We do not guarantee anything like that, we have built a network to allow the most efficient use of bandwidth to remote areas that have great challenges as far as delivering Internet access goes in comparison to companies that have physical cables available. We will do our best to increase speed and availability whenever and wherever we can, but what we have is what we have. You are not locked into any long term contract with us, please feel free to use someone else.
Please keep in mind that if we were building a network designed to show the fastest speed test results rather than a network that allowed the most of our customers to use the Internet in the most effective manner, we would have made different choices. We do not sell speed test results, we sell usable real world Internet access.
But my Internet is not working the way I want it to!
Please let us know what you are trying to do, and what is not working about it, and we will see if there is anything we can do. Sometimes there is, and sometimes there isn’t, but what you see on a speed test means very little to us.
For further information you can review the article: