50M : Speed test sites/HTTP proxy

[munrobasher]

I was on the point of thinking my 50Mbit/s link was degrading badly because most of the speed test sites, inc. speedtest.net were reporting around 5MBit/s most evenings. I did manage to get it to report 50Mbit/s early one morning.

But I've just downloaded a 2.5GB ISO image from Microsoft MSDN using their standalone File Transfer Manager and that managed ~4,000KB/s which is ~45MBit/s so I was perplexed.

My guess is that either a) the speed test sites are overloaded and not to be trusted by huge factor or b) VM is doing "something" with HTTP port 80 traffic such as using a transparent proxy server. Does anyone know if VM uses HTTP proxy servers upstream? If so, then maybe one of them is going bad or is completely swamped.

But as I write, I'm questioning my logic that maybe Microsoft file transfer manager uses a different protocol or port because when one looks at the options, there are checkboxes for HTTP and HTTPs. However, you can uncheck both and it still works. Maybe it tries custom protocol/port and if that doesn't work, falls back to HTTP. That would still make sense.

Any I making any sense personally though?

Cheers, Rob.

---------- Post added at 21:26 ---------- Previous post was at 21:21 ----------

I've just come across www.vmspeed.com which reports 40Mbit/s which is perfectly acceptable at this time of night.

So why is this speed test reasonably accurate and speedtest.net completely inaccurate? By a factor of 10?

Cheers, Rob.

[kwikbreaks]

That's part of the Virgin network...

Tracing route to www.vmspeed.com [80.0.239.6] over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms Tomato.HomeRouter [192.168.0.1]
2 10 ms 9 ms 10 ms cpc5-nrte25-2-0-w.8-4.cable.virginmedia.com [86.21.48.1]
3 11 ms 19 ms 12 ms nrth-core-b-ae2-2562.network.virginmedia.net [213.106.254.97]
4 8 ms 11 ms 12 ms nrth-bb-1b-ae8-0.network.virginmedia.net [213.105.159.209]
5 47 ms 19 ms 9 ms popl-bb-1a-as3-0.network.virginmedia.net [213.105.172.14]
6 13 ms 20 ms 17 ms asfd-core-1a-ge-00-0.network.virginmedia.net [212.43.163.29]
7 24 ms 19 ms 15 ms asfd-tam-1-ge01.network.virginmedia.net [80.3.97.22]
8 21 ms 24 ms 19 ms host80-0-239-6.no-dns-yet.ntli.net [80.0.239.6]

Trace complete.

Other speedtests (along with the rest of the internet) rely on VM's links to the internet and if they are congested you'll see poor speeds. Of course it could also be that every speedtest site you tried is congested and VM are perfect but I somehow doubt that.

[munrobasher]

Doesn't explain though how Microsoft's file transfer manager managed to sneak around and get a very high speed download.

I do suspect there's a transparent proxy out there somewhere...

Cheers, Rob.

[kwikbreaks]

Most download managers use multiple connections and most speedtests only use one.

There could be a transparent proxy involved I suppose but it's far more likely to be a simple case of what routing the traffic is going through. Do a search on this board for peering and you'll find some clues I'm sure.

[qasdfdsaq]

Originally Posted by munrobasher

I do suspect there's a transparent proxy out there somewhere...

There isn't.

I don't know why you keep banging on about proxies where it's totally irrelevant. The speed of network devices is not infinite. A transparent proxy is not required for a network device to slow down.

---------- Post added at 03:50 ---------- Previous post was at 03:50 ----------

Originally Posted by kwikbreaks

Most download managers use multiple connections and most speedtests only use one.

Speedtest.net (Ookla) by default uses 4 IIRC.

[munrobasher]

I don't know why you keep banging on about proxies where it's totally irrelevant. The speed of network devices is not infinite. A transparent proxy is not required for a network device to slow down.

Because as I point on in the thread, a bad transparent proxy could explain why HTTP traffic alone is throttled and not other traffic.

I concede there are lots of other reasons that could also explain slow HTTP connection/speed tests but if a network device slows down because it's overloaded, it tends to slow down all traffic.

That isn't "banging on" about something. It was asking a question, admitting by saying "am I making sense". How very rude.

All I was trying to point out was that for one type of traffic to be slowed down compared to others suggests that there is either something (and I admitted I didn't know what) was managing that traffic or the target server/connection (or route to that server) was overloaded. That could be a proxy server or HTTP traffic shaping/QOS (and most firewalls can throttle traffic).

I couldn't quite believe that speedtest.net itself could be at fault but it looks like this is the case. The Preston node (automatic choice for me) is struggling to get over 10MBit/s this morning but London and vmspeed.com report 50Mbit/s.

Whether the finger is still pointed at VM is looking less likely although it's still possible that the routing that's slow is still within VM's core network. I haven't got the energy to start looking at traceroutes.

Cheers, Rob.

---------- Post added at 10:26 ---------- Previous post was at 10:22 ----------

Another thread on why Preston speedtest.net is not the most reliable of nodes for testing:

http://community.virginmedia.com/t5/...ts-wrong-with-
speedtest-net/td-p/1132073

Cheers, Rob.

[qasdfdsaq]

Originally Posted by munrobasher

Because as I point on in the thread, a bad transparent proxy could explain why HTTP traffic alone is throttled and not other traffic.

So could bad weather or a bad cow. So could a million other things. There's no sane reason to suspect a transparent proxy over the million other far more likely and well known reasons.

I concede there are lots of other reasons that could also explain slow HTTP connection/speed tests but if a network device slows down because it's overloaded, it tends to slow down all traffic.

And there's no evidence to suggest it isn't.

That isn't "banging on" about something. It was asking a question, admitting by saying "am I making sense". How very rude.

You keep making up various random factors including things that don't exist for the slowdown.

All I was trying to point out was that for one type of traffic to be slowed down compared to others suggests that there is either something (and I admitted I didn't know what) was managing that traffic or the target server/connection (or route to that server) was overloaded. That could be a proxy server or HTTP traffic shaping/QOS (and most firewalls can throttle traffic).

Everyone knows VM traffic shape, and do so heavily. However you have presented no evidence to suggest HTTP traffic is being slowed down compared to others.

I couldn't quite believe that speedtest.net itself could be at fault but it looks like this is the case. The Preston node (automatic choice for me) is struggling to get over 10MBit/s this morning but London and vmspeed.com report 50Mbit/s.

Whether the finger is still pointed at VM is looking less likely although it's still possible that the routing that's slow is still within VM's core network. I haven't got the energy to start looking at traceroutes.

Preston server is on VM's network. If a VM customer is getting slow speeds to another part of VM's network, who would you point the finger at but VM?!

Originally Posted by munrobasher

Another thread on why Preston speedtest.net is not the most reliable of nodes for testing:

http://community.virginmedia.com/t5/...ts-wrong-with-
speedtest-net/td-p/1132073

Cheers, Rob.

As indicated in the other thread, the Preston server is perfectly reliable for anyone not on VM.

[kwikbreaks]

Originally Posted by qasdfdsaq

Speedtest.net (Ookla) by default uses 4 [connections] IIRC.

Thanks for the info - I've never checked but it could well explain why I find Speedtest.net gives faster results than some others - certainly for me when I was on 50Mbps TBB always showed slow in both it's results and my own monitoring while the test was in progress.