Peak time congestion issue

Hi,

I've been using Infinity through BT retail for just under a year having finally being able to access FTTC last January, until recentely it seemed fine but in the last month or so there have been some significant slow downs which seem to happen during the evening mainly.

I have tried all the obvious stuff and ruled out any issues within the house, done the livechat with BT 'help' who claim to have tested the line at their end and got 49Mbit when I was getting 7-9Mbit through speedtest.net and speedtest.btwholesale.com at the same time.

Conveniently their own speedtest which you can run when logged into your BT account for fault finding diagnosis always reports a problem saying it didn't complete then at the end of the other pointless bits they test says your 'speed appears normal' (how very convenient!).

Just looking for advice on what best to do next if anyone has had similar issues?, I've been through this before with ADSL which was pretty much exactly the same with it being terrible 7-11PM but fine after midnight in the last 2 years or so of using it, I got nowhere as they always denied the issue, so I'm hoping I am not going to find the same here, why do BT seem to plan so badly for bandwidh provision??.

Maybe I'm best to just cancel and try another ISP?, I'm not sure if my contract is 12 or 18 Months but given that the speed I'm getting is often well below their own minimum threshold I do not think it right that they can hold me to contract in any case!.

The speed thresholds usually apply to the connection speed, and speed to the ISP network, with no guarantees beyond there, so you need to establish first that your sync speed is stable

While speedtest.btwholesale.com is often favoured by providers it is not the ideal speed tester and speedtest.net can sometimes pick the odd bad host to test against. If you use http://www.thinkbroadband.com/speedtest this does two download tests with the first being more congestion sensitive and the routing is repeatable and well understood.

NOTE: Christmas and New Year are always expected to be slow due to everyone being online, so it may clear up on its own once the schools go back. The newspapers ran 'Internet meltdown' stories in their usual exaggeration stylee

http://www.thinkbroadband.com/speedtest/results.html...

Thanks for the reply, I will try it again tonight, though pretty sure it will be a lot lower, I'm on the 55Mbit package (52?).

Stats below from OR modem, quite scary as last time I logged in maybe 9-10 months ago my attainable rate was near 80Mbit!, looks like a lot of crosstalk?, meaning lots of new subscribers = contention?, makes sense as ADSL here was woeful but surely they should have known this would happen?.

I guess this is where they got the 49Mbit from as the sync speed not actual throughput then?, seems a bit silly but then this allows them to deny any problem so no suprise there.

Line Status

Downstream Upstream
Attainable rate (kbit/s) 47972 18375
SNR margin (dB) 18 0
Line attenuation (dB) 12.8 7.4
Output power (dBmV) 12.8 7.4

Statistics


Path 0

Path 1
Downstream Upstream Downstream Upstream
Line rate (kbit/s) 49478 9999 0 0
CRC errors 248 127 18 0
FEC errors 0 0 1 0
HEC errors 122 4294967290 32 0

Just as a side issue, you have posted there the stats from the GUI of the Openreach modem, where the attenuation and power figures are duplicated. IIRC it is the attenuation that is wrong.

You need to access the stats through telnet in a command window, if you know how to do that. Once logged into the modem the commands are:-

sh
xdslcmd info --stats

You can then copy and paste those to here, and we see the correct values plus several other useful figures.

49478 Sync speed, and maximum throughput will be ~96% of this, so 47498

The speed test shows something is oddly wrong, as the tbb single thread speed should not be that low compared to the multiple thread test. Some PlusNet users are reporting a similar problem, that then does go away or is fixed by restarting the modem. Is it a Home Hub 5a that you have?

The speed of the yellow line in the first 2 to 3 seconds looks to be the 45 Mbps and would expect a line to be able to hold that for the 8 seconds of the test, so that it drops suggests congested area maybe.

Cross-talk has vectoring to mitigate it, but does not always work well and is not fully deployed on VDSL2.

Contention - generally a lot better on VDSL2 services than ADSL2+ ones, but until we all are happy paying much higher prices the basic rule of consumer broadband that data from 1998 that it is a shared medium that WILL slow down when everyone is doing stuff still applies.

In reply to a post by MrSaffron:

NOTE: Christmas and New Year are always expected to be slow due to everyone being online, so it may clear up on its own once the schools go back. The newspapers ran 'Internet meltdown' stories in their usual exaggeration stylee

I, say.
Our Infinity 4 speed dropped halfway into the double figures over Christmas and the new year, it got bad to a point I was getting packet loss, or to a point the packets were delayed that long they was rejected.

BT says its not an issue until the speed drops below 30Mbps no matter what Infinity Package your on, which I think is wrong, I think it did that at some point new years due to all the packet loss etc.

Its still not back to normal, but is in the mid 3 digits (shown here) so not all bad atm.

But compared to what I normally get, i.e. speed result in my sig, it still seams people are either streaming or downloading stuff hence the congestion.

Paul

xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 18382 Kbps, Downstream rate = 47972 Kbps
Bearer: 0, Upstream rate = 9999 Kbps, Downstream rate = 49478 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.0 11.8
Attn(dB): 18.0 0.0
Pwr(dBm): 12.8 7.4
VDSL2 framing
Bearer 0
MSGc: -6 58
B: 235 236
M: 1 1
T: 0 23
R: 12 16
S: 0.1518 0.7543
L: 13070 2694
D: 8 1
I: 248 127
N: 248 254
Q: 8 0
V: 1 0
RxQueue: 39 0
TxQueue: 13 0
G.INP Framing: 18 0
G.INP lookback: 13 0
RRC bits: 0 24
Bearer 1
MSGc: 122 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 8.0000 0.0000
L: 32 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 328208
OHFErr: 1 11
RS: 1836171776 1604442
RSCorr: 3846135 66
RSUnCorr: 0 0
Bearer 1
OHF: 4355175 0
OHFErr: 0 0
RS: 34840902 0
RSCorr: 14 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 140476951 0
rtx_c: 37618 0
rtx_uc: 1 0

G.INP Counters
LEFTRS: 625 0
minEFTR: 49323 0
errFreeBits: 52754556 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2360098919 0
Data Cells: 92646638 0
Drop Cells: 0
Bit Errors: 0 0

Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0

ES: 1 10
SES: 0 0
UAS: 27 27
AS: 69955

Bearer 0
INP: 46.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 8.70
OR: 0.01 58.79
AgR: 49556.74 10057.90

Bearer 1
INP: 2.00 0.00
INPRein: 2.00 0.00
delay: 0 0
PER: 16.06 0.01
OR: 63.75 0.01
AgR: 63.75 0.01

Bitswap: 36081/36081 0/0

Total time = 19 hours 26 min 22 sec
FEC: 3846135 66
CRC: 1 11
ES: 1 10
SES: 0 0
UAS: 27 27
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 11 min 22 sec
FEC: 119208 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 26256 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 19 hours 26 min 22 sec
FEC: 3846135 66
CRC: 1 11
ES: 1 10
SES: 0 0
UAS: 27 27
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 19 hours 25 min 55 sec
FEC: 3846135 66
CRC: 1 11
ES: 1 10
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#

Post deleted by Spetznaz

Great - note the differences in the key figures as well. My memory was imperfect, as importantly the downstream SNR margin is the standard 6dB not the 18dB in the GUI version.

In the GUI, as well as the power figures being duplicated into the attenuation, the attenuation is moved into the SNR margin line.

There seem to be two things going on.

It looks as if your 80Mbps attainable of a year ago would be as one of the first users on the FTTC cabinet, and cross-talk as others have connected has seriously affected that. Given the attenuation of 18dB your current figures are poor but not disastrous. Unless you have already optimised your house (phone) wiring that could be the cause. Maybe even Christmas Lights on houses and Christmas trees, yours and neighbours.

Slow-downs in throughput at the ISP level, as MrSaffron says, could very well be down to heavy usage at this time of year, particularly with children off school and a lot of sport. At home similar could apply if you are connecting wirelessly to your router, or of course if anyone is using the connection at the time you test. The wireless connection itself could also be being affected by fancy lights and such.

Other info in the stats shows you on the basic level of G.INP, replacing earlier interleaving you will have had. Four million FECs in 20 hours looks a bit high to me.

In reply to a post by Spetznaz:

I am paying over £50 a month and would probably pay more for a decent service but it seems all your offered from BT is rubbish so you might as well pay £4 a month for Plusnet and be done with it ....

You aren't comparing like with like there.

On pricing I assume the £4 is a "first so many months" deal, and even then is amazing if it includes line rental. I see nothing on this page under £25pm for FTTC and that is an 18-month minimum term. The only £4 I see is for a call plan to go with it.

On the product itself, it is the Openreach 40/2 product, not the 55/10 you are on now. If upstream speed matters, then that is significant. You would also lose another 10Mbps downstream connection speed.

In reply to a post by Spetznaz:

Hi,

I've been using Infinity through BT retail for just under a year having finally being able to access FTTC last January, until recentely it seemed fine but in the last month or so there have been some significant slow downs which seem to happen during the evening mainly.

I have tried all the obvious stuff and ruled out any issues within the house, done the livechat with BT 'help' who claim to have tested the line at their end and got 49Mbit when I was getting 7-9Mbit through speedtest.net and speedtest.btwholesale.com at the same time.

Conveniently their own speedtest which you can run when logged into your BT account for fault finding diagnosis always reports a problem saying it didn't complete then at the end of the other pointless bits they test says your 'speed appears normal' (how very convenient!).

Just looking for advice on what best to do next if anyone has had similar issues?, I've been through this before with ADSL which was pretty much exactly the same with it being terrible 7-11PM but fine after midnight in the last 2 years or so of using it, I got nowhere as they always denied the issue, so I'm hoping I am not going to find the same here, why do BT seem to plan so badly for bandwidh provision??.

Maybe I'm best to just cancel and try another ISP?, I'm not sure if my contract is 12 or 18 Months but given that the speed I'm getting is often well below their own minimum threshold I do not think it right that they can hold me to contract in any case!.

Email Gavin Patterson - he will get his team in Newcastle to call you and they will probably shift you onto a less congested segment. That's what they did for me anyway

According to BT I was upgraded to the 55/10 package, I had a email to that effect anyway a few months back. I do understand the line rental thing, even so there are cheaper packages available, I checked my last bill which was around £60 (in total), seems steep for a 8Mbit service? (unless used at restricted times).

The attenuation figure seems odd, I am no expert but with ADSL wasn't it roughly 1dB per 100M?, I was (am) 2.0Km from the exchange and had 22-25 normally, the cabinet is around 650-750M max (line length) so surely it should be more like 9dB?.

I think you could be right about the lights, hopefully when these come down it may improve my sync slightly, I was one of the first yes and expected a drop off but it has been worse than expected, but then again as I said ADSL was almost unusable here so it was obvious a lot of people would move over quickly as they were effectively forced to, I thought G.INP or vectoring was supposed to offset this somewhat?.

I have a suspicion this issue has been going on for a few months but only got more noticeable over xmas, so I will see how it goes in the next couple of weeks now xmas is over, then I guess the only option is moving ISP and hoping they have more influence on BT than BT (hmm...) ?.

I can live with 30/40Mbit but when it is dipping well below 10Mbit I am basically back on ADSL and BT should only be able to bill me for this level of service, w!f is ofcom actually there for?.

Edited by deleted (Mon 02-Jan-17 19:11:01)

laaaaaaaaag..

Oh I'm back, thanks I'll give it a go but sounds too good to be true..

In reply to a post by Spetznaz:

According to BT I was upgraded to the 55/10 package, I had a email to that effect anyway a few months back. I do understand the line rental thing, even so there are cheaper packages available, I checked my last bill which was around £60 (in total), seems steep for a 8Mbit service? (unless used at restricted times).

Sorry, my post seems to have been a bit confusing.

I was pointing out that although you are now on 55/10 with BT, the rest of my post is about the Plusnet you suggest instead at £4pm. It is 40/2 resulting in probably under 38Mbps at good times. With a much lower upstream. Also I see no Plusnet package at £4 apart from an addon call plan.

The 8Mbps is the main issue of course, discussed by us all in other posts.

I'm exactly 600 metres from the cabinet, on a clean line, and my VDSL2 attenuation is 18.9dB. VDSL2 attenuates much more rapidly than ADSL2+. Graphs vary, but here's a reasonable one.

xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 200000
Last initialization procedure status: 0
Max: Upstream rate = 14321 Kbps, Downstream rate = 64316 Kbps
Bearer: 0, Upstream rate = 14306 Kbps, Downstream rate = 54999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 9.3 6.1
Attn(dB): 18.9 0.0
Pwr(dBm): 13.6 7.3

My 54999 sync and 9.3dB downstream noise margin are due to banding having been applied on my line a few months ago. I'm hoping that after a period of stability with my new modem DLM will remove the banding.

Note that on two HG612s I have used the highest sync achieved was under 60Mbps and the Max Attainable also under 60Mbps. With luck, once DLM relents I shall get well over 60Mbps actual connection speed. Also soon DLM will apply a 3dB margin instead of the default 6dB on the whole network. (Openreach are relaxing that, as BT Wholesale did a while ago on ADSL2+). That will add a few more Mbps I hope.

I was not expecting more than 55Mbit so sounds like I wasn't too far off, I was just hoping G.INP would improve things, hopefully it won't drop much more though at this point ISP congestion/cabinet congestion/exchange congestion (which ever it is!) is more of an issue than sync speed.

Thanks for the explanation.

Done and already got a reply similar to what you had by the sound of it, impressed so far as was not expecting a reply on a bank holiday evening, hopefully this rectifies things for me shortly but also means that OR become aware of an issue that is probably effecting other users in the area and work on improving capacity.

Thanks for the advice.

You might be mixing up G.INP and G.FAST.

G.FAST is the higher speeds than we have now, and is being trialled I think. G.INP is just an improved method of error handling instead of simple interleaving.

Simple interleaving that we had on FTTC for the first few years typically adds at least 8ms to latency, has a depth in the thousands, and reduces the sync speed by 7-10Mbps or even more.

G.INP goes with a very low depth of interleaving, eight or ten, and removes the extra latency. Almost the full speed of Fast Path is restored. But no extra. G.Fast gives higher product speeds, well above the 80/20 current max. As long as the line is short enough.

In reply to a post by Spetznaz:

Done and already got a reply similar to what you had by the sound of it, impressed so far as was not expecting a reply on a bank holiday evening, hopefully this rectifies things for me shortly but also means that OR become aware of an issue that is probably effecting other users in the area and work on improving capacity.

Thanks for the advice.

Did it resolve the issue for you?
I ask because my connection just dropped by 85% for several minutes and nobody else was using the connection at the time.

I only noticed it because I had just got loads of rubber banding in the game I was playing at the time and then got DC'd, I was also getting loads of errors over voice chat as well as seeing packet loss, so I did a speed test and was just shocked, it has been worse when I lost 95% of my connection, sadly I never kept a copy of the result.

Paul

In reply to a post by RobertoS:

I'm hoping that after a period of stability with my new modem DLM will remove the banding.

The line will need a DLM reset to remove the banding, it doesn't remove itself anymore.

Edited by deleted (Sun 22-Jan-17 16:16:42)

Anything to back that up please?

I've seen one reduction already, as (I think) I've posted. We have also recently seen on these forums other stepped reductions.

That's new, sorry I was just going on several reports from users on broadband forums. Yes, you may see a reduction in DLM retention but not necessarily banding.

Edited by deleted (Sun 22-Jan-17 19:21:14)

DLM retention? What do you mean by that?

Banding is auto removed on lines that are stable but had some major problem. It typically takes 2-4 months though.

On lines with a fault causing it to be banded then if handled properly by the engineer who fixes the fault it should be removed immediately with them requesting it from their control centre. If that isn't requested when closing off the fault though, then it's back to wait and pray.

I mean the loss in the strength of DLM's actions.

That's interesting, maybe something has changed because in the past, DLM used to band lines very quickly without applying other forms of pretection first, which as we know what DLM applies to a line first is removed last, but banding was never removed until a DLM reset was performed on some lines.

Banding certainly "sticks" on some lines. There's examples on MDWS where lines have been stable and ES rates have been well below the assumed limits for over a year, yet the banding has not budged. It does still work correctly sometimes though. Usually banding drops in stages, though it may not completely disappear.

I see no point rushing to ask for a DLM reset if the banding is say 35mb on a usually 37mb line. Such banding on a 60mb line is a different matter.

In reply to a post by RobertoS:

Banding is auto removed on lines that are stable but had some major problem. It typically takes 2-4 months though.

Banding used to be auto-removed, as you say. It used to take a while before reductions were considered, but the eventual removal would happen.

Since the middle of last year, when banding functionality seemed to be triggered more regularly, and banding increases (ie increasing severity) were applied more regularly too, we've seen that very bad cases do indeed get auto-reduced in severity. But the evidence is still that such reductions rarely continue on to a final removal of banding.

It was most noticeable last year, with changes in the G.INP switch-on mechanism. A line appeared to need DLM to fully undo all interleaving and banding settings before it would allow G.INP to be turned on instead. Yet banding seemed to be very sticky, and needed DLM resets.

Your line is one example, while the last report from @darrelr is another.

IIRC, @William's line was one caught up too, until he got a reset done.

I hope for this evidence to change. Banding that sticks permanently, even after temporary or accidental problems, is just not useful. Especially with such draconian requirements on getting a DLM reset performed.

Thanks, but . That's bad news. You think both darrelr and I are stuck by the sound of that.

I'm still going to give mine a while, seeing as it's previous long-running banding was 60Mbps. Though the more I think about it, and with this latest view from you, I may need to see what can be done.

Let's hope things change, as that's not how DLM should work. You could say my example was accidental, well no not really. XD.

Edited by deleted (Mon 23-Jan-17 12:55:54)

In reply to a post by WilliamGrimsley:

because in the past, DLM used to band lines very quickly without applying other forms of pretection first, which as we know what DLM applies to a line first is removed last, but banding was never removed until a DLM reset was performed on some lines.

What you are referring to as "in the past" seems to have been 2016 behaviour. If I remember correctly, your line was one of the early ones where we realised that banding had become (a) a choice that wasn't last resort, and (b) very very "sticky" (ie not removed).

That change in behaviour seemed to coincide with the 2nd attempt at putting G.INP on ECI cabinets. It also loosely coincided with BT reaching agreement with Assia over the DLM patent case. Whether those observations are a coincidence or causal, we don't (and won't) know.

@RobertoS is referring to behaviour prior to 2016, which is long-standing behaviour that we had all become very used to.

I wonder whether we'll see a new change in behaviour this year? We'll have another attempt at G.INP on ECI, and of course we have the rollout of lower SNRM targets too.

I doubt if the revised targets will be applied to banded lines - similar to that being the case on the trial.

In reply to a post by WWWombat:

I wonder whether we'll see a new change in behaviour this year? We'll have another attempt at G.INP on ECI, and of course we have the rollout of lower SNRM targets too.

Yes, it'd make sense that there'd be a change now Openreach are trialling 3, 4 and 5 dB downstream SNR margin's otherwise there'll be more reports of frustrated EU's. But, as we know with previous decisions made by Openreach, I'd take this as a pinch of salt.

Edited by deleted (Mon 23-Jan-17 13:04:45)

In reply to a post by RobertoS:

Thanks, but . That's bad news. You think both darrelr and I are stuck by the sound of that.

I'd love to be wrong, but the evidence so far is that you are indeed stuck.

I haven't become involved in people's DLM travails quite so closely for the last 4-5 months, but I have been keeping my eye open for changes in this particular aspect, and haven't seen it.

In general, I see the need for DLM, and understand its purpose. But this new behaviour is lame.

In reply to a post by RobertoS:

I'm still going to give mine a while, seeing as it's previous long-running banding was 60Mbps. Though the more I think about it, and with this latest view from you, I may need to see what can be done.

Please keep a log of what you get, whatever you choose. It's the only way we have to learn about DLM's ways.

One way of fixing it is to change Openreach product. I am told by a reliable source that resets DLM.

Not a solution for everyone of course but worth bearing in mind.

Not always, when I upgraded from the 40/10 to 52/10 package, it was still there.

It might have been on a concurrent migration, as the effect of a migration was the question I asked. I was told a like for like doesn't reset it, but a product change does.

I was thinking of a migration to fix it. Which means I would need to migrate to 40/10 then regrade back to 80/20 with the new ISP.

Fair enough, but wouldn't it be easier just to request a DLM reset, Openreach engineers will do it to save hastle.

You can't if you haven't got an engineer!

Plus the engineer doesn't reset it, they ask their control centre to do so, and the request can be and sometimes is refused. It is only supposed to be after finding the fault that caused it and fixing that fault. Not any old fault.

This is just out of curiosity, but why would the control centre refuse a DLM reset if there's a fault?

Nobody but they know. But obviously there can be faults that are nothing to do with causing banding.

In reply to a post by RobertoS:

I doubt if the revised targets will be applied to banded lines - similar to that being the case on the trial.

Perhaps. Probably, even.

You could think of "banding" and "adjustable SNRM targets" as two sides of the same coin, or at least similar currency.

A line that needs higher SNRM targets (that are a natural consequence of banding) isn't an obvious candidate for reduced SNRM targets ... but any process introduced to manage variable SNRM targets might, feasibly, become a better manager for variable banding too.

It'd make sense! Maybe this is a sign of things to come!

Edited by deleted (Mon 23-Jan-17 17:10:56)

And, of course, banding could have been caused by something that wasn't a fault on the phone line.

It can be hard to get Openreach to send an engineer in those circumstances. And impossible for an engineer to find a fault ... in which case (s)he may refuse to call the control centre.

Well, was mine actually to do with a fault?! I was just lucky that the Openreach engineer who picked the job up was one who'd visited the property loads of times in the past.

Which is why I have zero chance. Something that happened in I think the first half of 2016.

It would take me half an hour or so to find when I changed my sig sync to 60000kbps, by spot checking through my posts. Better things to do at the moment .