Orange? Wow...

Ok. I'm no dummy. wait a minute... maybe I am. Just moved to the UK and chose Orange DSL. Figured it'd be ok because the previous owner had it and said it was ok (must not have known any better). It's been a month. If you are looking for a provider, stay FAR FAR away from this company. Here's my history....

-sign up
-two weeks and connection not activated even though previous tenant had Orange.
-call and they say should be on the next day
-a week goes by
-go the store and they say i was lost in the system and sign me up again
-two more weeks go by
-connection finally starts
-internet completely unusable due to consistent ~20% packet loss
-isolate issue to something outside of the residence
-call and the polite/nice but unable to help rep state they are not allowed to escalate until "stabilization period" of 10 working days is complete (she didn't understand what DLM or packet loss is when I asked)
-packet loss went away for a day.
-now I see the below response time.

I could lament all the ways this impacts me professionally and personally but maybe I should just get the address of their accounts payable department and send an invoice for all my pain and suffering. Orange. You suck.

For the non-technical folks out there, the below shows no internet connection for almost four minutes, followed by waves of 5 second responses due to some type of throttling on the orange network. Average response time should be in the 100ms range. Absolute garbage.

$ ping google.com
PING google.com (209.85.143.104): 56 data bytes

64 bytes from 209.85.143.104: icmp_seq=210 ttl=50 time=5076 ms
64 bytes from 209.85.143.104: icmp_seq=211 ttl=50 time=4076 ms
64 bytes from 209.85.143.104: icmp_seq=212 ttl=50 time=3076 ms
64 bytes from 209.85.143.104: icmp_seq=213 ttl=50 time=2076 ms
64 bytes from 209.85.143.104: icmp_seq=214 ttl=50 time=1076 ms
64 bytes from 209.85.143.104: icmp_seq=215 ttl=50 time=76 ms
64 bytes from 209.85.143.104: icmp_seq=216 ttl=50 time=5064 ms
64 bytes from 209.85.143.104: icmp_seq=217 ttl=50 time=4064 ms
64 bytes from 209.85.143.104: icmp_seq=218 ttl=50 time=3064 ms
64 bytes from 209.85.143.104: icmp_seq=219 ttl=50 time=2064 ms
64 bytes from 209.85.143.104: icmp_seq=220 ttl=50 time=1064 ms
64 bytes from 209.85.143.104: icmp_seq=221 ttl=50 time=64 ms
64 bytes from 209.85.143.104: icmp_seq=222 ttl=50 time=5078 ms
64 bytes from 209.85.143.104: icmp_seq=223 ttl=50 time=4078 ms
64 bytes from 209.85.143.104: icmp_seq=224 ttl=50 time=3078 ms
64 bytes from 209.85.143.104: icmp_seq=225 ttl=50 time=2078 ms
64 bytes from 209.85.143.104: icmp_seq=226 ttl=50 time=1069 ms
64 bytes from 209.85.143.104: icmp_seq=227 ttl=50 time=69 ms
64 bytes from 209.85.143.104: icmp_seq=228 ttl=50 time=5117 ms
64 bytes from 209.85.143.104: icmp_seq=229 ttl=50 time=4117 ms
64 bytes from 209.85.143.104: icmp_seq=230 ttl=50 time=3117 ms
64 bytes from 209.85.143.104: icmp_seq=231 ttl=50 time=2117 ms
64 bytes from 209.85.143.104: icmp_seq=232 ttl=50 time=1117 ms
64 bytes from 209.85.143.104: icmp_seq=233 ttl=50 time=117 ms
64 bytes from 209.85.143.104: icmp_seq=234 ttl=50 time=5059 ms
64 bytes from 209.85.143.104: icmp_seq=235 ttl=50 time=4059 ms
64 bytes from 209.85.143.104: icmp_seq=236 ttl=50 time=3059 ms
64 bytes from 209.85.143.104: icmp_seq=237 ttl=50 time=2059 ms
64 bytes from 209.85.143.104: icmp_seq=238 ttl=50 time=1060 ms
64 bytes from 209.85.143.104: icmp_seq=239 ttl=50 time=60 ms
64 bytes from 209.85.143.104: icmp_seq=240 ttl=50 time=5066 ms
64 bytes from 209.85.143.104: icmp_seq=241 ttl=50 time=4066 ms
64 bytes from 209.85.143.104: icmp_seq=242 ttl=50 time=3066 ms
64 bytes from 209.85.143.104: icmp_seq=243 ttl=50 time=2066 ms
64 bytes from 209.85.143.104: icmp_seq=244 ttl=50 time=1066 ms
64 bytes from 209.85.143.104: icmp_seq=245 ttl=50 time=65 ms
64 bytes from 209.85.143.104: icmp_seq=246 ttl=50 time=5081 ms
64 bytes from 209.85.143.104: icmp_seq=247 ttl=50 time=4081 ms
64 bytes from 209.85.143.104: icmp_seq=248 ttl=50 time=3081 ms
64 bytes from 209.85.143.104: icmp_seq=249 ttl=50 time=2081 ms
64 bytes from 209.85.143.104: icmp_seq=250 ttl=50 time=1081 ms
64 bytes from 209.85.143.104: icmp_seq=251 ttl=50 time=81 ms
...

This isn't throttling, this is a line error.

That was my initial thought when I saw the packet loss. I'm more of a network guy (cable HE systems) and every time I've seen packet loss it was a physical issue (bad port, wire, card, etc.). But when the packet loss went away I was kind of scratching my head. I have seen overloaded ATM circuits demonstrate the response profile in my first post. Not sure if that's what this is here.

The question is, do I walk in the store and demand they release me from contract and try another provider? Or am I doomed with a BT-owned physical issue that will be present no matter who I choose?

My neighbors all have the Virgin option but being I'm in a class2 listed building I'm the only block on the street without. Maybe run a 200' crossover cable through a neighbors window?

err, you could use wireless or 3g too.

Thing is, it shouldn't be that bad, there's definitely something wrong. You probably need to get that sorted out as any ISP connection may be the same.

I don't see why you can't get Virgin cable in a listed building though.

The class 2 thing, yeah, I dunno. That's what Virgin told me. I need to figure out what path will get me on a stable connection the quickest.

The packet loss thing is never fun. I've been on way too many concalls with providers trying to guide their network teams in narrowing down the source of the issue with traffic captures between nodes. Same story everytime. So my hopes of convincing the sometimes indifferent customer service reps at Orange to get to get someone out that can figure this out are a little dim. I'll flash them best smile and give them my most woeful story this weekend but we'll see where that goes.

Options? Let's say, hypothetically of course, that you happened to know someone that architected the LDAP service for a major provider and hard coded in a test account that could be used to authenticate with any shared partner across the world. Then you would have free wifi anywhere you can get a signal. My dilemma is that at times I need a fast and stable connection so I don't have to run out of the house when something critical comes up or mess around with alternate connection methods when I want to do connect real quick and my Orange connection is acting a fool.

Nice flat, but if Orange can't resolve the line issue for me before my lease is up I will be moving to another place and forever curse their name.

I guess what I really need is a place to vent and get a quick sanity check. Thank you thinkbroadband.com !

Edited by deleted (Thu 19-May-11 21:14:50)

More of the same this AM. Ugh. Did a little research and I'm leaning towards thinking that I have a mix of a line and CDVT issue. Let's say the line was perfect and this was strictly related to traffic shaping... Would BT or Orange have control over these parameters? IOW, Does Orange have administrative control over leased circuits such that they are responsible for QoS profiles?
....
64 bytes from 209.85.143.99: icmp_seq=1728 ttl=50 time=5055 ms
64 bytes from 209.85.143.99: icmp_seq=1729 ttl=50 time=4055 ms
64 bytes from 209.85.143.99: icmp_seq=1730 ttl=50 time=3055 ms
64 bytes from 209.85.143.99: icmp_seq=1731 ttl=50 time=2054 ms
64 bytes from 209.85.143.99: icmp_seq=1732 ttl=50 time=1055 ms
64 bytes from 209.85.143.99: icmp_seq=1733 ttl=50 time=55 ms
64 bytes from 209.85.143.99: icmp_seq=1734 ttl=50 time=5060 ms
64 bytes from 209.85.143.99: icmp_seq=1735 ttl=50 time=4060 ms
64 bytes from 209.85.143.99: icmp_seq=1736 ttl=50 time=3061 ms
64 bytes from 209.85.143.99: icmp_seq=1737 ttl=50 time=2061 ms
64 bytes from 209.85.143.99: icmp_seq=1738 ttl=50 time=1061 ms
64 bytes from 209.85.143.99: icmp_seq=1739 ttl=50 time=61 ms

----google.com PING Statistics----
2269 packets transmitted, 897 packets received, 60.5% packet loss
round-trip (ms) min/avg/max/med = 53/2593/5173/3055

OK. Done looking for now. If you have any advice or another take BatBoy I appreciate it. Just found this thread which is dated but interesting...

http://web.archiveorange.com/archive/v/yqqaaw0HXd9x3...

HI, sorry to hear of your Orange woes. I joined them last year and the broadband was connected within 3 hours on the day they stated it would be.
Orange is in the process of moving their customers to BT WBC 21CN network the all-digital exchange.

what exchange are you connected to? It might put us more in the picture.

http://www.samknows.com/broadband/exchange_search

And what figures do your router stats give?

2Wire 2700HGV router.
DSL Connection Details
Protocol: G.DMT2+ Annex A
Downstream Rate: 11830 kbps
Upstream Rate: 1153 kbps
Channel: Interleaved
Current Noise Margin: 10.0 dB (Downstream), 5.8 dB (Upstream)
Current Attenuation: 30.2 dB (Downstream), 14.8 dB (Upstream)
Current Output Power: 18.5 dBm (Downstream), 11.9 dBm (Upstream)
DSLAM Vendor Information: Country: {0xB5} Vendor: {BDCM} Specific: {0x9662}

Edited by deleted (Fri 20-May-11 11:03:15)

/// Connection is decent when I just logged in. Here's the exchange...

http://www.samknows.com/broadband/exchange/STWINCH

/// Here's the stats of the moment, I'll take another snapshot when things go sour again...

ADSL Link Downstream Upstream
Connection Speed 14808 kbps 1168 kbps
Line Attenuation 24.6 db 12.6 db
Noise Margin 5.1 db 6.8 db

/// During primetime I logged 5 minute spikes of some serious latency different than the earlier noted 5 second burst pattern...

64 bytes from 209.85.149.99: icmp_seq=14068 ttl=248 time=20672 ms
64 bytes from 209.85.149.99: icmp_seq=14069 ttl=248 time=19672 ms
64 bytes from 209.85.149.99: icmp_seq=14070 ttl=248 time=18672 ms
64 bytes from 209.85.149.99: icmp_seq=14071 ttl=248 time=17672 ms
64 bytes from 209.85.149.99: icmp_seq=14072 ttl=248 time=16672 ms
64 bytes from 209.85.149.99: icmp_seq=14073 ttl=248 time=15671 ms
64 bytes from 209.85.149.99: icmp_seq=14074 ttl=248 time=14671 ms
64 bytes from 209.85.149.99: icmp_seq=14075 ttl=248 time=13671 ms
64 bytes from 209.85.149.99: icmp_seq=14076 ttl=248 time=12671 ms
64 bytes from 209.85.149.99: icmp_seq=14077 ttl=248 time=11672 ms
64 bytes from 209.85.149.99: icmp_seq=14078 ttl=248 time=10672 ms
64 bytes from 209.85.149.99: icmp_seq=14079 ttl=248 time=9672 ms
64 bytes from 209.85.149.99: icmp_seq=14080 ttl=248 time=265473 ms
64 bytes from 209.85.149.99: icmp_seq=14081 ttl=248 time=264473 ms
64 bytes from 209.85.149.99: icmp_seq=14082 ttl=248 time=263473 ms
64 bytes from 209.85.149.99: icmp_seq=14083 ttl=248 time=262473 ms
64 bytes from 209.85.149.99: icmp_seq=14084 ttl=248 time=261471 ms

Do a tracert and see which part of the link between you and the servers is struggling.

C:>tracert 209.85.143.104

Tracing route to dy-in-f104.1e100.net [209.85.143.104]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms xx.xx.xx.xx
2 46 ms 47 ms 46 ms lns4.uan.thn.uk.murphx.net [xx.xx.xx.xx]
3 47 ms 46 ms 47 ms uan-er1.uan.thn.uk.murphx.net [xx.xx.xx.xx]
4 162 ms 130 ms 47 ms ge2-6-1.cr1.core.thn.uk.murphx.net [89.145.254.1
61]
5 46 ms 46 ms 46 ms te2-3.cr05.tn5.bb.gxn.net [62.72.139.97]
6 * * * Request timed out.
7 50 ms 47 ms 58 ms 209.85.255.175
8 62 ms 61 ms 61 ms 209.85.250.216
9 60 ms 60 ms 60 ms 209.85.253.203