Look like TBB had finally fix the speedtest - got it correct this time on 30 Meg:

for me higher but no cigar.



http://www.speedtest.net/result/1156658341.png

from tbb to me.

# Host Sent Recvd Best Avg Worst
1 thinkbroadband-gw2.core-rs2.thdo.ncuk.net 15 15 0ms 3ms 27ms
2 gi4-47-10-star1.bdr-rt3.thdo.ncuk.net 15 15 0ms 3ms 47ms
3 linx-gw2.router.ntli.net 15 15 0ms 0ms 0ms
4 brnt-bb-1b-as0-0.network.virginmedia.net 15 15 0ms 2ms 13ms
5 brnt-bb-1b-ae5-0.network.virginmedia.net 15 15 0ms 5ms 75ms
6 brnt-bb-1a-ae0-0.network.virginmedia.net 15 15 0ms 1ms 8ms
8 leic-core-1b-as0-0.network.virginmedia.net 15 15 4ms 4ms 4ms
9 leic-cmts-14-gigaether-141.network.virginmedia.net 15 15 4ms 5ms 7ms
10 <censored>.cable.virginmedia.com 15 15 11ms 12ms 14ms

Edited by Chrysalis (Mon 14-Feb-11 06:03:13)

In reply to a post by aj2703:

That is dated 20-12-10.

Do one now....

Certainly.



Network is busy, lunchtime and all that, so apologies for the slightly slow performance.

In reply to a post by Chrysalis:

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.

Back to BGP school Chrys actually the receiver of traffic is the one with the control really.

TBB aren't manipulating traffic in any way, it's not their job to route around issues on VM's network, if VM don't want that peering link used they can stop advertising prefixes on it, or advertise a subset, or use AS path prepending or one of the many other things they do as standard to manage traffic on their network borders.

In reply to a post by Chrysalis:

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).

Nothing old about that router particularly that IP address just hasn't had its DNS updated.

When it became Virgin Media they didn't just throw out all the ntl T320s, T640s, etc, most of the core network is ex-ntl kit.

I say irrelevant due to that tbb seems to be the only place where this happens. Say "speedtest", and you generally imagine the speed that the user is able to achieve on their line, not the speed to a specific site. TBB's problems do not reflect real world results.

What's also strange is that while their java based one gives terrible performance:



The flash one comes much closer to real world speed.

Still doesn't match a dedicated speedtest site however, London / Paris

In reply to a post by Roph:

I say irrelevant due to that tbb seems to be the only place where this happens. Say "speedtest", and you generally imagine the speed that the user is able to achieve on their line, not the speed to a specific site. TBB's problems do not reflect real world results.

What's also strange is that while their java based one gives terrible performance:



The flash one comes much closer to real world speed.

Still doesn't match a dedicated speedtest site however, London / Paris

The flash one clearly shows why you weren't getting maximum speed, there's a few dips in transfer rate. The Ookla tests don't appear to reflect this.

The difference between the Java and Flash is interesting, I suspect it is in part due to the difference in payloads between the two - that would need someone with TBB To confirm.

I guess a part of it is what you want to see, do you want your 'real' speed or your peak one?

In reply to a post by Ignitionnet:

In reply to a post by Chrysalis:

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.

Back to BGP school Chrys actually the receiver of traffic is the one with the control really.

TBB aren't manipulating traffic in any way, it's not their job to route around issues on VM's network, if VM don't want that peering link used they can stop advertising prefixes on it, or advertise a subset, or use AS path prepending or one of the many other things they do as standard to manage traffic on their network borders.

the sender can also manipulate tho as they can stop announcing to certian networks to force a routing change. I never said VM are blameless, just it is not a complete one sided issue. It still raises the question how I cannot get other linx side hosts to go over that specific route and repeat the same performance issues.

In reply to a post by Ignitionnet:

In reply to a post by Roph:

I say irrelevant due to that tbb seems to be the only place where this happens. Say "speedtest", and you generally imagine the speed that the user is able to achieve on their line, not the speed to a specific site. TBB's problems do not reflect real world results.

What's also strange is that while their java based one gives terrible performance:



The flash one comes much closer to real world speed.

Still doesn't match a dedicated speedtest site however, London / Paris

The flash one clearly shows why you weren't getting maximum speed, there's a few dips in transfer rate. The Ookla tests don't appear to reflect this.

The difference between the Java and Flash is interesting, I suspect it is in part due to the difference in payloads between the two - that would need someone with TBB To confirm.

I guess a part of it is what you want to see, do you want your 'real' speed or your peak one?

for what its worth I agree with you on ookla.

for this reason I watch dumeter during tests, as dumeter shows live throughput. on ookla it does sustain my full throughput now VM have sorted out local congestion issues, however in the past eg when I was on VM's legacy network I can see how ookla gave false results, I would see dumeter spike once during test to 10mbit/sec for a split second and then finish off crawling 0.2mbit/sec, bam 9-10mbit/sec speedtest result. It takes some account of slowdown but generally not enough. Also I think tbb is single threaded vs 4 threaded ookla so ookla has leniancy on low tcp buffer sizes + retransmits as well. So ookla can show misleading results but at the moment in my case it is not.

also even tho I am questioning why tbb is having thie unique issue compared to other uk hosts, I know enough to know VM have transit issues, real world performance indicates that as various http sites will give me low download performance, however generally its not low enough that it causes a real concern usually at least 5mbit/sec or so. just that I rarely fully utilise the line capability.
no idea how to post the flash result here, cannot see a button to click on for link.

It got 26.4 down 0.98 up which is interesting.

dumeter showed it initially spike to about 29-mbit/sec and then levelled of at about 26mbit/sec. This could be a tcp buffer issue or could be congestion, I will repeat the test in early hours and if it doesnt improve its less likely to be congestion.

Edited by Chrysalis (Mon 14-Feb-11 18:42:45)

That's quite good considering the time of day