In reply to a post by RobertoS:

How about you think about what might be causing the OP's real-use problem with throughput? Ignore the tests if you wish.

Are you saying you can read the OP's mind? Because

"I have observed a "slowness" to my general internet experience lately"

is a very vague statement. So please do share precisely what he/she means by "slowness" because the OP didn't expand on that.

What the OP did make clear was, they wanted to know why the TBB results were lower than Ookla's. So based on my experience and some other posters - such as those with Vodafone & Virgin Media - I suggested the TBB tester doesn't always give out the correct results, for whatever reason.

Does that make sense now?

In reply to a post by baby_frogmella:

Ignoring the OPs issues, �.

Then perhaps you'd like to expand on the OP's issues wrt "slowness"? You seem to know more than the rest of us...

In reply to a post by MrSaffron:

Have tried that and I am seeing different behaviour that supports the peak speed theory

Have also seen it on other peoples connections when watching video recorded of the test

The theory that state is that 25% of the slow samples and 15% of the fast samples are rejected and then an average calculated, but that does not seem to be the case all the time.

Isn�t the rejecting of upper and lower percentages only relevant to the legacy fall back Http speed test service? According to Ookla documentation most speed tests use TCP which doesn�t have the requirement to download lots of little files and remove the upper 2 and lower 1/4 samples. Instead TCP uses the end speed achieved after trying to force max throughout via the adjustment of chunk and buffer size.

Which would suggest that by making those changes it should pretty much always report close to max line speed - which is great if you want to know what your line speed is. It doesn't do much to assess the real world performance of the line and so if used by ISPs in diagnosing issues it will generally just look like the line is fine so they close the call.

In reply to a post by ian72:

Which would suggest that by making those changes it should pretty much always report close to max line speed - which is great if you want to know what your line speed is. It doesn't do much to assess the real world performance of the line and so if used by ISPs in diagnosing issues it will generally just look like the line is fine so they close the call.

Yeah, I don�t think it�s ideal for anything other than showing how fast the line is. My point being though that in either test scenario it doesn�t take the peak speed achieved at any point in the test. So if you hit 50mb for a millisecond but the rest of test is around 45, and for tcp ends at 45mb, then 45mb is what you get, not the unrealistic 50mb.

speedtest.net is very much testing over HTTP protocol. Seems to use use TCP port 8080

Remember HTTP is built on the TCP protocol

Mine always starts off slow then builds up ive no idea why

https://www.thinkbroadband.com/speedtest/15783370627...

Edited by beefcakechipz (Mon 06-Jan-20 19:06:51)

In reply to a post by MrSaffron:

speedtest.net is very much testing over HTTP protocol. Seems to use use TCP port 8080

Remember HTTP is built on the TCP protocol

This link explains better than I why they are differentiating the TCP test from their HTTP fallback. In the main anyone with a new browser is being pushed to the TCP test.

https://help.speedtest.net/hc/en-us/articles/3600386...

So Google Chrome is not a new browser?