Mind you- it could be a lot worse than it is.

A tbb IPv6 speedtest, done this morning:

Detailed Results
Date 23/04/11 11:31:51
Download speed 189.33 Kbps (0.18 Mbps)
Upload speed 7415.23 Kbps (7.24 Mbps)
Server Port 8095 (tcp)

And a link to one on a French server a few minutes earlier:

IPv6 speedtest

Edited by billford (Sat 23-Apr-11 14:57:04)

And one more to add: Port 80 tests do not wok either! They were find in ADSL days but not VDSL/FTTC

It's definitely either the Java tester itself or the servers, as I have full speeds everywhere else, and at peak times TBB tester would say otherwise.

I'm pretty sure it's not the tester itself- on occasion I can get full-speed results comparable with the BT one. But mostly it only shows 60-70% of that speed.

Same for me, and sometimes lower than 50%.

.

In reply to a post by MHC:

And one more to add: Port 80 tests do not wok either! They were find in ADSL days but not VDSL/FTTC

Port 80 just worked fine for me? Maybe you need to stir the wok?

Edited by RobertoS (Sun 24-Apr-11 13:50:19)

That is the point ... there seems to be quite a few problems arising with FTTC but some people get one or two, others get a different set and other suffer none at all.

It's a shame this is still an ongoing problem.

I had FFTC installed last summer and at the time I raised the issue of the TBB speedtest not working properly but I was told in no uncertain terms that there's no problem their end and it's our fault we're not seeing accurate results.

Edit - http://forums.thinkbroadband.com/newsite/t/3894231-r...

Edited by deleted (Sun 24-Apr-11 15:07:58)

Thanks for the responses. Unfortunately that means I can't rely on Thinkbroadband to test my FTTC throughput.

Could it be IP address related, depending on which IP address or subnet you are assigned? Though I've had 14Mbps and 20Mbps with the same IP.

Today TBB is higher but still low 20360 Kbps, compared with the BT speedtester 29349Kbps.

Robert
Basingstoke

Hi,

I don't know if this would help anybody out at all.

from http://www.speedguide.net/articles/windows-7-vista-2...

Compound TCP - Improve throughput
Add-On Congestion Control Provider

The traditional slow-start and congestion avoidance algorithms in TCP help avoid network congestion by gradually increasing the TCP window at the beginning of transfers until the TCP Receive Window boundary is reached, or packet loss occurs. For broadband internet connections that combine high TCP Window with higher latency (high BDP), these algorithms do not increase the TCP windows fast enough to fully utilize the bandwidth of the connection.

Compound TCP (CTCP) is a newer method, available in Vista and Server 2008 (there is also a hotfix available for XP/2003). CTCP increases the TCP send window more aggressively for broadband connections (with large RWIN and BDP). CTCP attempts to maximize throughput by monitoring delay variations and packet loss. It also ensures that its behavior does not impact other TCP connections negatively.

By default, Vista and Windows 7 have CTCP turned off, it is only on by default under Server 2008. Turning this option on can significantly increase throughput.

To enable CTCP, in elevated command prompt type:

netsh int tcp set global congestionprovider=ctcp

To disable CTCP:

netsh int tcp set global congestionprovider=none

Possible options are: ctcp, none, default (restores the system default value).
Recommended setting: ctcp

It is better to use this newer generation CTCP congestion control algorithm for most broadband connections, we highly recommend it being turned on.