Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Xup]

^^ Added to the above post

[cliver]

Interesting event this morning on my line:
At 06:46 this morning I got an email from MyDSLWebStats informing me of a Resync on my line.

On investigation I find that my sync rate has dropped from 48 to 44Mbps.
Interestingly my Max Attainable has gone up from 46 to 50 Mbps though.
My SNRM seems to have gone up at the same time but I guess that may be down to the reduced sync rate?
Looking at my stats it seems to be a massive increase in FEC errors which is still going on  .
Ping has gone out to 30mS with a commensurate drop in speed test results.
G.INP is still off.

Is this normal "training period" behaviour?
On TT from memory, my line settled quite quickly and was pretty solid most of the time.

One thing I cant get my mind around is the fact that with TT I was in the "Standard" profile getting syncs of >50Mbps
and speed tests consistently in the 49-50Mbps range and pings of 20mS.
Now with BT I'm on the "Speed" Profile getting Lower Sync, speed tests and higher pings.
I know I have to give it time (it's day 3 now), but if this doesn't settle I'll be pulling out from the contract and going back to TT.
I'm cliver on mydslwebstats.co.uk if anyone wants to have a look.

Regards
Clive

[j0hn]

As G.INP still isn't active on the line, your ES rate had been too high, triggering DLM. If you look at the traffic lights on MDWS you can see the limits and that you're in the red.

DLM has introduced interleaving and FEC error correction to try reduce the ES. Nothing to worry about, this reduces sync a little. When G.INP comes back online you will get all this back.

The interleaving also increases pings a little, as can be clearly seen on your TBB ping graph. Switching back to Talktalk won't make any difference. If anything the wait time for G.INP to return will start again. The allowed ES rate on Talktalk is also half what it is on BT so you would probably have triggered DLM easier.

Ignore anything BT told you about giving it 3 days etc. There is absolutely no training period on FTTC. DLM is already acting on your line, so if there was a training period, it's over. You just need to be patient and wait for G.INP.

[cliver]

As G.INP still isn't active on the line, your ES rate had been too high, triggering DLM. If you look at the traffic lights on MDWS you can see the limits and that you're in the red.

DLM has introduced interleaving and FEC error correction to try reduce the ES. Nothing to worry about, this reduces sync a little. When G.INP comes back online you will get all this back.

Thanks j0hn, my main worry was the sudden and quite dramatic leap in FEC errors, which seem to be slowly settling back down now though.
The traffic lights on MDWS have been amber on the down link, and close to the red, since the change to BT. It's I'd because it was the uplink that was amber and died more errors on TT.
Anyway, let's see what happens if/when G.IMP cuts in.
Thanks again.

Sent from my Nexus 6P using Tapatalk

[cliver]

Just to clarify for my simple mind.
Is the increase in FEC errors I'm seeing due to the retrain and not the other way around as I was initially thinking?
In other words is the increase showing that the retrain has done it's job and more errors are getting corrected.

Sent from my Nexus 6P using Tapatalk

[roseway]

FEC's are a consequence, not a cause of anything. DLM only considers actual errors and connection drops. FECs aren't actual errors, they are packets of data which would have been errors if they hadn't been corrected by the forward error correction (FEC) system.

[cliver]

FEC's are a consequence, not a cause of anything. DLM only considers actual errors and connection drops. FECs aren't actual errors, they are packets of data which would have been errors if they hadn't been corrected by the forward error correction (FEC) system.

Thanks roseway, so the FEC's are the effect of the retrain rather than the cause.
Should the number of FEC's I'm seeing now appear as CTC or other errors in the stats prior to the retrain?
I'll have a look at the other errors to see if I can pinpoint what caused the retrain. I assume the FEC's I'm seeing now would be CRC or other errors before the retrain took place?

Sent from my Nexus 6P using Tapatalk

[cliver]

Right, I think I'm getting my mind around this (albeit slowly .
Looking at my average errors they have shifted from CRC's  to FEC's since the retrain.

Average error rates for 01 Oct 2016 (Before retrain)

CRC erors per hour:  1193 Down,  10.2 Up
FEC erors per hour:  0 Down,  25.2 Up
HEC erors per hour:  2543 Down,  0 Up
ES per hour:  190 Down,  9.00 Up
SES per hour:  3.00 Down,  0 Up

Average error rates for 02 Oct 2016 (After retrain)

CRC erors per hour:  284 Down,  6.85 Up
FEC erors per hour:  26999 Down,  14.1 Up
HEC erors per hour:  689 Down,  0 Up
ES per hour:  70.1 Down,  6.17 Up
SES per hour:  1.14 Down,  0 Up

I have quite high interleaving on at the moment 865/1 which I believe accounts for the high ping of 30mS.

Slowly getting my head around the stats and cause and effect of various changes. 

[roseway]

At a guess, your interleaving depth was increased by DLM as part of the latest retrain, and this resulted in more real errors (CRCs) being replaced by FECs.

[cliver]

At a guess, your interleaving depth was increased by DLM as part of the latest retrain, and this resulted in more real errors (CRCs) being replaced by FECs.

Yes interleaving is now 865/1

[j0hn]

That's pretty much how it works. You had no interleaving, and no error correction applied before the resync. You were on "fastpath" with a completely open line. This has allowed a large number of CRC's and ES. The DLM is only interested in ES. Your line went over the 2880 ES per 24 limit allowed by the Speed profile, so DLM forced a resync and applied interleaving and forward error correction (FEC). This corrects errors before they happen, reducing the number of CRC's & ES. When G.INP comes back on the FEC stops doing it's job. G.INP is a more efficient way of preventing errors.

[cliver]

Thanks guys, I'll look forward to G.IMP switching in.
I'm just trying to Skype for the first time since I cut over to BT and for some reason my camera isn't sending a picture. Wonder if that's a latency issue 🤔

Sent from my Nexus 6P using Tapatalk

[cliver]

Yay! G.INP cut in overnight. Ping now down to 20mS DL 48Mbps UL 9Mbps.
Pretty much exactly what I was getting on TT. 5 weeks since BT took over the line.

Sent from my Nexus 6P using Tapatalk

[raislander]

Mine came back yesterday, 3 weeks since the line changed hands from Sky. Seems that the DLM may act faster on some lines???

[cliver]

Mine came back yesterday, 3 weeks since the line changed hands from Sky. Seems that the DLM may act faster on some lines???

Yes I'm not sure what criteria it users to decide when to switch G.IMP on but I'm guessing it's something to do with the level of short error bursts it sees as that's where it comes into its own I believe.

Sent from my Nexus 6P using Tapatalk