Slow throughput. ISP apparently unable to help - now what?

According to the BT speed tester my profile is 76.7/20. Since last Tuesday my throughput has struggled to average 30Mb/s - prior to that I consistently got 60Mb/s. I've run BT speed tests in the afternoon, the evening and at 7am. They all give more or less the same results. I've been in discussions with IDNet support but aside from suggesting new tests to run (boot into safe mode, try a different machine, plug a computer directly into the BT modem) nothing made any difference.

Now it seems they've given up. They say it's not their network (which seems reasonable because I don't see hoards of other IDNetters complaining). All they can suggest is congestion at the cabinet and that BT will do nothing about it until throughput drops below 12Mb/s.

To me this is ridiculous. I live in the middle of a housing estate so I struggle to see how cabinet congestion can be 24/7. Our exchange was only enabled two months ago. Also there's almost no variability. It's 30/10 all the time. Secondly things were fine until Tuesday the 19th. Are we to believe that everyone on my cabinet suddenly woke up Tuesday and decided to dedicate their lives to downloading stuff 24/7?

So my question is - where do I go from here? Apparently IDNet are powerless to do anything about it. I'm going to check with a neighbour this evening if they are in but is this really the bright new 80/20 future that BT had in mind? The fault threshold is only 1Mb/s higher than my old Be connection.

Edited by Andrue (Tue 26-Jun-12 12:12:12)

All they can suggest is congestion at the cabinet and that BT will do nothing about it until throughput drops below 12Mb/s

The Openreach CIR is I think 30M for the 80M service, while the 12 may be a BT Wholesale end to end thing.

The 1 Gig fibre to a card serving 48 users is consistent with 20 Mbits/s CIR for Openreach GEA.

I'd expect it to be a BT Wholesale WBC thing

In reply to a post by MrSaffron:

I'd expect it to be a BT Wholesale WBC thing

It's the BT speedtester that states that. It says acceptable throughput is 12Mb/s to 76.7Mb/s.

All you can do really is laugh. Imagine going to buy a car from a dealer and being told acceptable top speed is 12mph to 76mph. Only in the mystical world of BTw could such a huge range be quoted as a acceptable :-/

I just find the whole thing extremely irritating to my engineer sensibilities. Something changed. The connection is clearly operating well below it's potential now. Yet apparently all is fine in the world

Edited by Andrue (Tue 26-Jun-12 12:29:16)

In reply to a post by Andrue:

To me this is ridiculous. I live in the middle of a housing estate so I struggle to see how cabinet congestion can be 24/7. Our exchange was only enabled two months ago. Also there's almost no variability. It's 30/10 all the time. Secondly things were fine until Tuesday the 19th. Are we to believe that everyone on my cabinet suddenly woke up Tuesday and decided to dedicate their lives to downloading stuff 24/7?

Don't know if this is relevant:-

What speed will lines with the 80/20 product variant receive when the network is congested?

Openreach has implemented a downstream Prioritisation Rate (PR) for each of our downstream product bandwidth variants. In the event of network congestion, we will decrease line speeds momentarily to reduce the congestion as follows:
Product bandwidth variant purchased Prioritisation rate
Up to 40Mbit/s 15Mbit/s
Up to 80Mbit/s 30Mbit/s


The whole briefing can be seen here Openreach Briefing

Could it simply be that "something" is incorrectly putting you on the prioritised 30Mb "congested" setting?

In reply to a post by Bald_Eagle1:

Could it simply be that "something" is incorrectly putting you on the prioritised 30Mb "congested" setting?

It could be. That makes some sense. Or maybe there really is congestion - although the fact it's there at 7am makes that unlikely. It is interesting that the upload appears unaffected.

The one thing I didn't mention here is that when this happened the latency reported by speedtest.net to my preferred server dropped from 35ms to 15ms.

It's the BT speedtester that states that.

Wholesale then.

It is a contended service, that's why it's the price it is. I don't know if Openreach can do diagnostics that demonstrate their holding their end of the bargain up at 20M+

the latency reported by speedtest.net to my preferred server dropped from 35ms to 15ms.

If it's less interleaved than it was (or not interleaved) that might be part of the story - packet corruption & retransmission. An unfiltered phone can make a solid 8M ADSL line useless from interference and data corruption, so I imagine there a similar effect in VDSL. Probably need some low level statistics or diagnostics to see it.

Maybe the OP's virtual path has changed ? That might account for the solidly different speed, and the change in latency.

I wonder why Idnet haven't looked any further in to this. The usual action is to send an engineer on an FTTC3 fault. If that all checks out OK, then the issue must lie with BT Wholesale or possibly even Idnet. (They don't run one of those strange additional profile jobbies like Plusnet do they ?)

In reply to a post by yarwell:

It is a contended service, that's why it's the price it is. I don't know if Openreach can do diagnostics that demonstrate their holding their end of the bargain up at 20M+

Yeah. But apparently it was contended at 6:38am this morning. The same level of contention apparently as at 9:15pm last night.

That seems a bit weird to me. Brackley is a small rural town so I'm surprised that I can't find any time of day when throughput is back to the way it was. Also surprised that the effect is consistent. But having come from Be I have no experience of overly contended networks so perhaps this is normal.

In reply to a post by Andrue:

But having come from Be I have no experience of overly contended networks so perhaps this is normal.

No, I don't think it is normal. It reads as though there IS a problem with your line, it's just going to take some effort to find it and your ISP really should be leading the charge. I get full throughput on my line (around 61-62Mbps) at virtually all times and I am subject to Plusnet's traffic management and do not pay the extra to have my connection unthrottled.

Edited by kasg (Wed 27-Jun-12 09:36:50)

In reply to a post by kasg:

In reply to a post by Andrue:

But having come from Be I have no experience of overly contended networks so perhaps this is normal.

No, I don't think it is normal. It reads as though there IS a problem with your line, it's just going to take some effort to find it and your ISP really should be leading the charge. I get full throughput on my line (around 61-62Mbps) at virtually all times and I am subject to Plusnet's traffic management and do not pay the extra to have my connection unthrottled.

Well things I have yet to try:
* Unlocking the modem - scheduled for Saturday.
* Talking to a neighbour about their connection - in progress.

I've also sent another email to IDNet support pointing out the following in the Openreach GEA specification:

What if I need to raise a fault on an 80/20 line?
We are changing the test thresholds within our GEA service test that we use to accept faults. From 19th March 2012 there will be no need to wait until your line speed has dropped below a specific fault threshold rate. Openreach provides a full fault diagnostic process that picks up the major causes of speed issues. Any found on an end user�s line will be picked up by our test systems and we�ll accept a fault for investigation. For further details see Section 3.9 of the GEA over FTTC product description.

I don't know if that applies to the BTw service though and probably not. I don't mind (not much) if BT comes back with 'yeah, there's a problem it'll take a while to fix'. What bothers me is the sheer frustration arising from what seems IDNet's impotence to do anything. The idea that 'we have no idea what's going on and can't do anything to help' is an acceptable response from a service provider is appalling.

Edited by Andrue (Wed 27-Jun-12 11:04:31)