BTW if anyone wants to test their speed, we have a speedtest here on our servers.
Speedtest.net Mini Bandwidth Speed Test
Its actually been there for about 2 years.
I find it interesting Scott, that this is same test as
one of those under scrutiny in this topic. But I assume you just rent the right to use somebody else's product. Not surprisingly, the mini-test demonstrates the identical issue with upload speed results. Specifically, results are demonstrably inflated when simultaneously compared to the bitstream at point of origin. For example; I might be sending a measured 170k, the test site reports back 250k. The mini-server is seeing a proprietary bitstream on the satellite side of the modem - which is compressed
and FEC encoded
and already suffering from at least 500ms of lag. On the other hand, I can simultaneously sample the raw bitstream on the WAN - between the modem and the PC. And as you know, the raw bitstream is the one that defines true operating speed. Inroute overhead isn't added until processed by the subscriber modem. Outroute analysis is similar, but usually employs far less FEC - so needs a separate speed test algorithm of its own.
Besides, the upload test file is grossly undersized. The (minimum) half second lag
alone makes a simple
throughput over time calculation wildly inappropriate. But that's the easy part. The real stumbling block is how to accurately factor in the various and proprietary transmission methods. You likely already understand burst transmission. But for those that don't, the gateway server must be given sufficient time to set a throttle appropriate to the rate plan specific to that bitstream. As such, the initial transmission will be a burst that is considerably in excess of that permitted by the rate plan. It however is passed through to the test server. But in this case, the upload test file itself is so small - and the lag is so great -
that the test is over before the properly throttled bitstream gets properly factored into the test results. It's long been accepted that 300k is the smallest file size recommended for typical consumer grade satellite inroute testing. But the real cherry on top is that both TX and RX data rate and coding are adaptive. At least that's true for my provider. Specifically, it's possible (for my modem) to shift data and/or FEC rates in mid-test; a factor that simply can NOT be taken into consideration by a 3rd party test server.
That said, the fact that each satellite provider employs a proprietary transmission method - works
against the speed test provider. It's just not practical to tailor individual speed tests on a provider basis. The guy that thinks he's going to come up with a
universally accurate speed test for ALL satellite connections - is tilting at windmills. Which is yet another reason to stick with diagnostic tools specific to the satellite provider.
Anyway. I also find it interesting that
bwporker (which I assume stands for
Bandwidth Hog) and
Bandwidth are both Floridians. Given the similarity of their screen names and coincidental proximity, I'm curious if they also post from the same IP address. Have a good time in Denver by the way !!
//greg//