UPC Throttling Speeds

Nollog

niall0s wrote: »

Downloads from OVH before 2am 200.37kB/s, after 2am and before 7am 2.00MB/s

I've been getting 50-100kB/s all day, and it goes up to about 200kB/s late.

niall0s

Yeah, I just tried it there and maxing out at 100kB/s download but 1.0MB/s upload

What a joke....

I know they read this thread now too (my contact told me) so I expect them to cripple the upload speeds soon to make it look less obvious

Snake Plisken

They have been screwing me since last June, I get crap speeds during the main usage hours of 6pm to midnight, they admitted it's a congestion issue as I get close to 30meg in off peak times (2am). I was told that my area was oversubscribed and that they where going to carry out segmentation work, back in November I was told this would be December, this got pushed out to January due to snow, ring them again in Jan told work slipped to February and i should ring back beginning of March I've let it lie till the middle of march rang them this week to be told the work has been complete but I'm stilling speeds around 11mb during peaktimes even lower sometimes. Got yesterday evening and they got me to run a tracert with modem directly into pc, it seems to hit what i think is the local node ip address before it gets to the ntlworld ip address and times out intermittantly see below


Tracing route to www.rte.ie.nsatc.net [89.207.56.140]
over a maximum of 30 hops:

1 2 ms 1 ms <1 ms 192.168.0.1
2 12 ms 9 ms 8 ms my upc ip address
3 * * 27 ms 188.141.126.209
4 10 ms 10 ms 11 ms 089-101-175030.ntlworld.ie [89.101.175.30]
5 10 ms 22 ms 12 ms mat-r-10ge-0-0-3.rte.ie [193.242.111.42]
6 10 ms 31 ms 18 ms www.rte.ie [89.207.56.140]

Trace complete.

guy couldn't tell me what that ip address beginning 188 on line 3 was, then the phone got mysteriously disconnected last night and he didn't ring me back last night or today.

Next move will be to drop down to the 20 meg package, but before I want to negotiate a major credit to my account due to lack of provision of services paid for!

niall0s

Worrying that the guy didn't recognise the address of one of their own routers....

It's been causing problems for a long time, see thread here http://www.boards.ie/vbulletin/showthread.php?t=2055948008

Snake Plisken

niall0s wrote: »

Worrying that the guy didn't recognise the address of one of their own routers....

It's been causing problems for a long time, see thread here http://www.boards.ie/vbulletin/showthread.php?t=2055948008

Yeah and he was supposed to be level 2 tech :eek:

Thanks for the link, it's a shame they can't provide the service they advertise, tired of paying for a service that they cannot provide

matt-dublin

i would say that the router in question has been configured to limit/block icmp packet requests otherwise the next hop would be horrible

Spear

Snake Plisken wrote: »

Yeah and he was supposed to be level 2 tech :eek:

Thanks for the link, it's a shame they can't provide the service they advertise, tired of paying for a service that they cannot provide

Or maybe he realised that the dropped ICMP packets at routers are normal and to be expected, and that traceroute shows nothing wrong. So far there's been nothing in the thread that shows any sign of throttling by UPC, just people making unfounded assumptions that UPC have infinite bandwidth over every peering and transit link to every other network.

matt-dublin

Spear wrote: »

Or maybe he realised that the dropped ICMP packets at routers are normal and to be expected, and that traceroute shows nothing wrong. So far there's been nothing in the thread that shows any sign of throttling by UPC, just people making unfounded assumptions that UPC have infinite bandwidth over every peering and transit link to every other network.

absolutly agree, i definitly think most of the issues are due to peering policies and peering bandwidth allocation.

Snake Plisken

lads, im not downloading anything, the UPC guy was the one who suggested running tracert, I don't care if they are traffic shaping I just want what I pay for during the time I want to use it, and all I'm getting is strung along by this shower!

niall0s

Spear wrote: »

So far there's been nothing in the thread that shows any sign of throttling by UPC, just people making unfounded assumptions that UPC have infinite bandwidth over every peering and transit link to every other network.

1. I proved it using glasnost
2. I was told they do it by someone who works in their NOC
3. Testing connection right now to OVH, Download speed 200kB/s, Upload speed 1.0MB/s (if it was a peering problem the upload would also be affected)

matt-dublin

i would say its congestion and a peering issue for definite.

i arrived home today and was downloading unencrypted torrents at 2.5MB

on a 20Mb connection i don't think thats too bad. If they were shaping i would definitly not be able to do that.

shaping on http downloads would be the least of their priorities, if they were going to shape it would be on torrent packets as most people who use UPC use it for gaming, voice or for torrenting.

I do know as a fact that they give priority to cs4 voice traffic on their network, where voice is priortised above all for home users.

the traceroute shows no issues, blocking icmp traffic at router level is a standard practise especially if the router is doing more then just routing.

the logic behind it all (especially if you have a lot of high torrent downloaders in your area) is how many people can you fit through a door at any one time, ie. the bottleneck affect.

in greystones, i have no issues any time or day, ovh.com/net latency is high, but i see that as the route its taking being pretty crap and i blame that on upcs peering policy not traffic shaping

matt-dublin

you proved that their is high utilisation during peak times not traffic shaping.

if there was a peering issue, high peak utilisation on that peer that would take the same route as ovh would cause the issue

why would upc chape traffic to another web hosting provider and ISP????

by that logic they should be shaping heanet traffic. UPC can only guarantee speeds to their own network. after that its a third party.

the only way you can !00% prove traffic shaping is by looking at the QoS policies on their end

all glasnost is doing is guestimating your upload download times using specific ports and java, if you're not reaching their estimated baselines for download times they're assuming your being shaped.

glasnost wrote:

Glasnost tests work by measuring and comparing the performance of different application flows between your host and our measurement servers

Spear

niall0s wrote: »

1. I proved it using glasnost
2. I was told they do it by someone who works in their NOC
3. Testing connection right now to OVH, Download speed 200kB/s, Upload speed 1.0MB/s (if it was a peering problem the upload would also be affected)

1. I'm still reading the Glasnost paper, I'll come back to this part later.

2. The statement from your mate in UPC sounds off. Why would they throttle against certain IP ranges? The major content sources are on CDN's spread on a very wide and variable set of addresses. This smacks more of a peering or transit issue, either congestion or maybe just expensive to use.

3. This is just wrong. If the traffic exchange on a no settlement peering arrangement had become grossly asymmetric, it's all the more reason for UPC to want avoid using to as to help prevent it becoming less desirable to the peer network and the loss of the settlement free status.

This all sounds more like congestion on certain links. If they wanted to throttle there's much juicier and more productive targets such as FMS or Bittorrent traffic.

niall0s

Spear wrote: »

2. The statement from your mate in UPC sounds off. Why would they throttle against certain IP ranges? The major content sources are on CDN's spread on a very wide and variable set of addresses. This smacks more of a peering or transit issue, either congestion or maybe just expensive to use.

This all sounds more like congestion on certain links. If they wanted to throttle there's much juicier and more productive targets such as FMS or Bittorrent traffic.

Fair enough, just saying, I know they are doing it, they know they are doing it, I've got a workaround the puts my line back up to 100% to OVH so their shaping ways are no longer annoying me that much

matt-dublin

well do tell your workround.

Nollog

niall0s wrote: »

1. I proved it using glasnost
2. I was told they do it by someone who works in their NOC
3. Testing connection right now to OVH, Download speed 200kB/s, Upload speed 1.0MB/s (if it was a peering problem the upload would also be affected)

I'm not sure glasnost is proof.

matt-dublin wrote: »

i would say its congestion and a peering issue for definite.

i arrived home today and was downloading unencrypted torrents at 2.5MB

on a 20Mb connection i don't think thats too bad. If they were shaping i would definitly not be able to do that.

shaping on http downloads would be the least of their priorities, if they were going to shape it would be on torrent packets as most people who use UPC use it for gaming, voice or for torrenting.

I do know as a fact that they give priority to cs4 voice traffic on their network, where voice is priortised above all for home users.

the traceroute shows no issues, blocking icmp traffic at router level is a standard practise especially if the router is doing more then just routing.

the logic behind it all (especially if you have a lot of high torrent downloaders in your area) is how many people can you fit through a door at any one time, ie. the bottleneck affect.

in greystones, i have no issues any time or day, ovh.com/net latency is high, but i see that as the route its taking being pretty crap and i blame that on upcs peering policy not traffic shaping

What you said supports shaping.
You can download a torrent at 2.5MB/s yet I can't FTP from a 100mbit box over 60kB/s all day today.

matt-dublin wrote: »

you proved that their is high utilisation during peak times not traffic shaping.

if there was a peering issue, high peak utilisation on that peer that would take the same route as ovh would cause the issue

All day every day with the past two weeks in my case, and there's only 1 other UPC router in my 18dbi range.
Not peak or high utilisation issue.

Spear wrote: »

This all sounds more like congestion on certain links. If they wanted to throttle there's much juicier and more productive targets such as FMS or Bittorrent traffic.

If it was congestion, the speeds would vary wildly.
I'm downloading within a 10kb range 90% of the time. And never get above 101kB/s.

matt-dublin wrote: »

well do tell your workround.

VPN.
I'm not sure if that proves shaping, or bad route, as the VPN would fix the routing issue if they use a better route.
Then on the other side, it's tunneling through a non-OVH IP which can bypass their throttle if there is one on OVH ranges.

matt-dublin

what i said up there doesn't prove shaping, i just FTP'd 100mb from my office here upc, there eircom, and i achieved 17.2mb throughput

if they were shaping, they would be definitly shaping unencrypted torrent packets so why would i be achieving 20Mb on a 20Mb circuit?

where from and to are you ftping from.

what is the result of your speed test from upc.ie

Nollog

matt-dublin wrote: »

what i said up there doesn't prove shaping, i just FTP'd 100mb from my office here upc, there eircom, and i achieved 17.2mb throughput

if they were shaping, they would be definitly shaping unencrypted torrent packets so why would i be achieving 20Mb on a 20Mb circuit?

where from and to are you ftping from.

what is the result of your speed test from upc.ie

They're obviously not shaping the entire internet.
Golly gosh fellow.

Read my posts on the last page to see where I'm having problems.
Everything else is fine, but the server I rent is with OVH.
So I expect better service, and hope it's a bad route as they'll be more likely to fix that than to change a newly implemented policy regarding throttling.

matt-dublin

you're right, they're obviously not shaping the whole internet, but you will find however its highly unlikely that they're shaping one specific type of traffic (ftp) to one specific provider.

you'll probably find not if its a bad route, Munster Broadband have been trying to peer with them for months and months now but they won't for some reason (methings they're not big enough)

its more likely a routing issue on a third party, something like a bad bgp peer advertisement and route weight.

i've also spotted that ovh servers are used heavily as seedboxes, and you looks like they're subject to several lawsuits about it as well so i wouldn't be surprised if ovh are doing the shaping themselves as part of a lawsuit requisite, it even lookg like google doesn't allow some specific search terms and references to them

Nollog

matt-dublin wrote: »

you're right, they're obviously not shaping the whole internet, but you will find however its highly unlikely that they're shaping one specific type of traffic (ftp) to one specific provider.

i've also spotted that ovh servers are used heavily as seedboxes, and you looks like they're subject to several lawsuits about it as well so i wouldn't be surprised if ovh are doing the shaping themselves as part of a lawsuit requisite, it even lookg like google doesn't allow some specific search terms and references to them

They're not shaping Just FTP, they're shaping everything to OVH-based IP addresses.(If they are)

True, some users ruin it for the rest of us.
OVH would be breaking their own terms by limiting traffic though, so it's less likely than UPC which say they can limit traffic in their terms.
They said it wasn't them, so I'd imagine they told the truth.
If it was court-ordered, I'm pretty sure they'd have to tell me.

Try downloading this from your UPC connection:
http://demo.ovh.net/view/5d811a4897e243be9e3336b071ae06be/0 (Click the box)
I'll bet you get < 101kB/s

conor.hogan.2

I get faster megavideo and youtube when I use a proxy - so they must be throttling.

user1842

It states that UPC broadband is congestion free on their website. Does that mean there is no contention ratio? That the connection is 1:1? Or are they just playing with words?

dumb_parade

dmclean1842 wrote: »

It states that UPC broadband is congestion free on their website. Does that mean there is no contention ratio? That the connection is 1:1? Or are they just playing with words?

I wondered that too, but it think its fair to say that a contention ratio of 1:1 is not the same as congestion free in UPC land.

thefinalstage

dmclean1842 wrote: »

It states that UPC broadband is congestion free on their website. Does that mean there is no contention ratio? That the connection is 1:1? Or are they just playing with words?

Congestion free means you will get the speed your line can take consistently day or night.

The contention rate last time I checked was 12:1

user1842

poisonedstream wrote: »

Congestion free means you will get the speed your line can take consistently day or night.

The contention rate last time I checked was 12:1

Ok but if they can guarantee speed than the contention ratio does not matter no?

thefinalstage

dmclean1842 wrote: »

Ok but if they can guarantee speed than the contention ratio does not matter no?

Generally no but it leaves them with an excuse if their service gets slow speeds.

niall0s

dumb_parade wrote: »

I wondered that too, but it think its fair to say that a contention ratio of 1:1 is not the same as congestion free in UPC land.

This is the same company that defines Unlimited as something with a limit

banchang

Glasnost test result (I have 100MG UPC)

Your ISP appears to rate limit your BitTorrent downloads. In our tests, downloads using control flows achieved up to 6638 Kbps while downloads using BitTorrent achieved up to 8681 Kbps.

There is no indication that your ISP rate limits downloads on port 6881 or 34221. In our tests, downloads on port 6881 achieved up to 7850 Kbps while downloads on port 34221 achieved up to 6638 Kbps.

How do I interpret this ? Should I change anything ?