In reply to a post by aj2703:

http://www.speedtest.net/

What do you get on that one?.

http://www.speedtest.net/result/1155734757.png Spot on speed
Incorrect speed

Edited by adslmax (Sun 13-Feb-11 14:15:56)

Your connection is as it should be. I think the problem lies with the thinkbroadband speeedtester.

Just ignore TBB's speed tester, it's poor quailty generally irrelevant.

In reply to a post by Ignitionnet:

In reply to a post by adslmax:

How to fix TBB speedtest ? I try port 80 and without port 80 , no different. Getting wrong speed 17 meg out of 30 Meg on cable ?

Ask Virgin to upgrade their transit and peering rather than shaping and hoping that will alleviate the need to?

I ran the traceroute tool on the website to see how tbb gets to VM and it goes over linx and over an old ntl switch (still says ntl in rdns).

here is my speedtest.



tbb has always been shaky to VM but this is the worst I have seen it, it never once spiked above about 4mbit/sec so there is some serious congestion between tbb and VM. My suggestion to tbb is do a post on it on the news page and bad PR will shake VM into action. Assuming this is a VM side issue, I also wonder if its worth to try and route this differently by changing the announces.

Is it VM's linx link thats saturated again? if you know that is. As I remember when I was on ntl half a decade back they had saturated linx then.

In reply to a post by adslmax:

In reply to a post by Ignitionnet:

In reply to a post by adslmax:

How to fix TBB speedtest ? I try port 80 and without port 80 , no different. Getting wrong speed 17 meg out of 30 Meg on cable ?

Ask Virgin to upgrade their transit and peering rather than shaping and hoping that will alleviate the need to?

I test it after 9pm & overnight as there shouldn't be any shaping trafic using TBB from virgin media's end.

I think TBB need to look into this and get it fixed asap.

You could also try reading what I said again. The capacity issue is with Virgin and they introduced shaping to try and avoid upgrading.

Also recommend you check the shaping hours, it doesn't end at 9PM.

Or you could carry on thinking that TBB have no capacity issues to anyone except Virgin but it's TBB's fault

In reply to a post by Roph:

Just ignore TBB's speed tester, it's poor quailty generally irrelevant.

TBB's speed tester is the most accurate one publicly available and considerably better than the Ookla based tests which are quite flattering to ISPs. If being accurate is considered poor quality so be it

As a reminder a speed test is as fast as the slowest point. It's interesting how many people seem to think that slow point is the fault of TBB when pretty much everyone else is fine, including people who test from 100Mbps fibre connections.

It's really strange that this poor quality tester that can't manage more than a few Mbits to Virgin Media customers appears able to do this for me...



Sadly other people were using the rest of the 100Mbps so couldn't have it all to myself - upload is rate limited locally.

In reply to a post by BipolarBear:

In reply to a post by MrSaffron:

You can think we are passing the buck, but can assure you we are not.

I've seen speedtest.net report 150Meg on a VM 100Meg link, interesting result. Wonder how many of the speedtest.net servers are actually hosted on 100Meg versus GigE.

http://blog.thinkbroadband.com/2011/01/net-neutralit...
The methodology used in our tester is more likely to show that congestion up, than what is used on speedtest.net

the least you could do is put a notice on the speedchecker page to let VM users know that they're likely wasting their time. I know of a number of users who have spent time on the phone with support purely because of the erroneous results produced by the TBB checker.

This would seem good to me. If enough people phone up VM may stop trying to delay by shaping and traffic management (I am talking there in terms of routing, not Subscriber Traffic Management) and adequately upgrade their external capacity to cope with demand.

In reply to a post by Ignitionnet:

In reply to a post by adslmax:

In reply to a post by Ignitionnet:

... nested quotes trimmed ...

Ask Virgin to upgrade their transit and peering rather than shaping and hoping that will alleviate the need to?

I test it after 9pm & overnight as there shouldn't be any shaping trafic using TBB from virgin media's end.

I think TBB need to look into this and get it fixed asap.

You could also try reading what I said again. The capacity issue is with Virgin and they introduced shaping to try and avoid upgrading.

Also recommend you check the shaping hours, it doesn't end at 9PM.

Or you could carry on thinking that TBB have no capacity issues to anyone except Virgin but it's TBB's fault

I agree, I do remember also when I was on a diff ip range speedio testing was also affected by congested transit.

What I dont understand is VM spending money on local UBR updates which I would assume is quite expensive but skimp out on transit which now days is dirt cheap compared to a decade ago.

If you know tho I am curious, is it the linx peering link again?

Edited by Chrysalis (Sun 13-Feb-11 22:13:24)

That is dated 20-12-10.

Do one now....

In reply to a post by aj2703:

That is dated 20-12-10.

Do one now....

one thing has got me thinking. it may be a paranoia view and I guess only the tbb foudner's can comment on this.

the article on tbb's site shows how an isp can manipulate performance depending on how it routes traffic (correctly). VM would have no motivation to route tbb traffic slowly as it will only damage their rep but tbb does seem to be a pro adsl site, I have tried to duplicate the inbound routing using other hosts that go via linx and I cannot get the same route to my VM connection, they all avoid linx or at least avoid that specific linx route as if its been deprioritised (maybe VM consider it faulty?). So because of that I couldnt test from another host using that route on VM.

So my thoughts are as to a reason why the routing hasnt been changed or if it cannot be changed as to why. The sending host can do this.