Print

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

[Ixel]

I'm also trying to determine if the FEC is considered at all during DLM's decisioning process (e.g. for positive changes). The ASUS gives out an unusually high FEC count when interleaved with a lower SNRM, but based on their technical explaination I think it's understandable - just different . I'm hoping FEC isn't considered, but I'm applying enough interleaving (INP/delay) to reduce standard error seconds my line produces on most modem chipsets anyway. Once a month has passed and no changes have occurred and I know nothing negative could've changed its decision further then I'll post an update to conclude whether or not FEC is really considered.

[Chrysalis]

well as they use MTBE and FEC's are not errors they shouldnt be doing so.

[jid]

you need to stay out of red status for the length of caution counters, then it should take action.  I am not sure tho if needs to be green or if amber is ok, kitz or someone else hopefully can tell you.

I too am unsure of this, however, so far its green all the way.

[kitz]

Always have since Fibre was installed and they've not caused problems in the past?

NS is correct.  We've seen several cases now where powerline adapters have been the definite cause of problems.  In fact there's a couple of models that have been banned in Norway because of the noise interference they generate, yet they are still for sale in the UK
-link.

I am not sure tho if needs to be green or if amber is ok, kitz or someone else hopefully can tell you.

Its got to be green for an improvement.  Amber keeps you at the same profile.  Red puts you on a higher profile.

Dont forget that different ISPs may not all be using the same profile categories. (ie speed etc) http://www.kitz.co.uk/adsl/DLM_calculator.php

[kitz]

I'm also trying to determine if the FEC is considered at all during DLM's decisioning process

Ive spent hours and hours searching through documentation and no where (aside from the Zen website) have I ever seen mention of FECs.   All the BT documentation says either just "Errors" or when they get more specific "Code Violations".   FECs are certainly not code violations.   

Ive also put out a few feelers and contacted several people - See here.
2 separate sources have confirmed E/S and SES.

Im still ploughing my way through all the DLM stuff but had to come to a temporary halt because of the huge amount of time this was taking to read through all the papers and documents and sort out what was relevant and what isnt. Its a massive project and far bigger than I imagined it would be when I first started.  I think only someone like the ISPs or perhaps BS will understand just how hard it is to get information.  Its there but it takes a heck of a lot of decyphering and wading through irrelevant information that there is so much of. 

 Ive also contacted someone to request the current BToR DLM MTBE, they promised they would get back to me with some figures or confirmation, but so far Ive heard nothing as the ASSIA case kind of dropped a bombshell and BT seem to be pretty stum now.    All I can do is confirm that the figures that I had prior to the ASSIA case seem to have been the most up to date at that point.  Ive no idea what has been changed (if anything) since.


Perhaps in the New Year, I may have time to do some more digging,  theres bits of more info that I have yet havent yet penned, but anything that Im pretty certain of my facts on, will be going up on this page.   
http://www.kitz.co.uk/adsl/DLM.htm
where Im attempting to methodically work through the whole process.

[Ixel]

...

Ok thanks, that would make sense as different modem chipsets can produce different FEC values (in some cases, significantly different it would seem) - plus they are corrected errors and don't appear to truly represent the potential CRC errors either.

As quoted from ASUS:

Please note that the root cause of high FEC is Noise. Firstly, we assume that there is no Noise and the channel is perfect, the Receiver(Modem) get the constellation point is the exact point (we call it golden point for the time being) that the Transmitter(DSLAM) sent, so there is no FEC at all.
 
Secondly, there is slight noise and the channel is not perfect, the Receiver(Modem) get the constellation point is not the point that the Transmitter(DSLAM) sent, if Receiver(Modem) get the point is very close to the Transmitter sent than other constellation point, then the channel coding (such as RS code and decode) can correct it to the golden point, so FEC will be produced which is normal.

A little bit of broken English.

EDIT:
Only two things I've noticed on DLM so far since they restored it.

1) DLM seems to take action later in the morning than usual, typically between 7am to 9am here.
2) Minimum sync rate is now 128Kbps instead of approximately half of the maximum sync rate.

[jid]

Its got to be green for an improvement.  Amber keeps you at the same profile.  Red puts you on a higher profile.

Dont forget that different ISPs may not all be using the same profile categories. (ie speed etc) http://www.kitz.co.uk/adsl/DLM_calculator.php

I know that I'm on "Stable" for IPTV - or at least I assume so considering TalkTalk mentioned TV customers are on a different DLM profile. So far since disconnecting the HG612 - which caused lots of errors - the connection is settling to 1 - 3 ES a day. Just a matter of waiting now I guess

Thanks for the reply, makes sense of a few more things

1) DLM seems to take action later in the morning than usual, typically between 7am to 9am here.

I've noticed this too, after 9am I had one.

[kitz]

Thanks for the info

1) DLM seems to take action later in the morning than usual, typically between 7am to 9am here.

Im not too certain if that is related to the ASSIA case or not.   I noticed the change in October (slightly before the ASSIA court case) that any DLM changes could now happen at any time up to 11am - typically at 10am - rather than the previous wee small hours.  In this thread on the 25th of Oct I specifically commented on how much later changes to the DLM were now being made. 

My fault occurred whilst BT were messing about with something on the backhauls - most possibly changing the SVLANs to do with the new MSE bRAS... because this was the time that I suddenly found out I was now routing via a neighbouring exchange rather than my own local exchange.

If you notice the first DLM change occurred during night time hours.. then suddenly they were all during daytime hours.

-----

Over the past few months BT have been doing a heck of a lot of re-routing and changes in relation to the MSE bRAS.  This means (for me at least) the Element Manager for my FTTC DSLAM (which communicates the DLM changes) is no longer in my local exchange, but instead in the next town.   The RAMBo box also wont be in my local exchange, so I suppose there could be an awful lot of boxes & element managers that are kept busier and monitoring more lines and making DLM changes later in the day.    On the old system its possible that you could have had just one element manager for one MSAN.. now youre going to get element managers that are responsible for an awful lot of fttc cabs.

To me it would make more sense that the later DLM changes are more to do with the new MSE bRAS rather than anything to do with the ASSIA court case.

2) Minimum sync rate is now 128Kbps instead of approximately half of the maximum sync rate.

After reading through a lot of the court case notes, the one over-riding area in which ASSIA seemed to have a stronghold was that BT used caps & banding for the fttc system. 
There also seemed to be some sort of issue with BT holding some sort of records and the use of banding.   We know that the court case only affected the fttc system and therefore banding..  so I suppose this could be part of it.   I dont see that ASSIA had a problem with SNR and Interleaving (OK they tried it - but BT counter claimed that this had been used elsewhere and considered normal adsl practice pre-dating the ASSIA patent).   

[NewtronStar]

It's one of those strange FEC things Interleaved and non-Interleaved when your Interleaved the FEC's will be higher than if you had a non-Interleaving line yet the errored seconds are higher on the non-Interleaved line than the Interleaved line, so those hidden FEC counts could be accumulated as FEC counts onto the errored seconds and the reason why non-interleavers have higher errored seconds 

[kitz]

Its not strange.  Look at it this way.


Day 1

Line A & Line B & Line C are on fast path and all lines start getting lots of CRCs (which lead to E/S).  This is bad because data has to be re-transmitted and the line feels laggy and pages can be slow to load.   The DLM detects that all three go red for MBTE so it applies Interleaving to all lines.

Day 2.

Line A The line performs perfectly.  Its now getting a few FECs but no ErrSecs.  MTBE is green.  DLM assumes that the previous day must have been a one off so removes interleaving. 

Line B The line peforms a lot better, its now getting lots of  FECs but that doesnt matter because through error correction the modem can recover most of the lost data. So theres less dropped packets, less loss data.  Because its now getting FECs, theres not as many ErrSecs.    The FEC count shows that Interleaving and Error correction is working as it should be, so DLM doesnt care. As long as MTBE stays amber then the DLM wont do anything and leave the level of interleaving as it is.

Line C The line performs better, its now getting lots of FECs but its still getting quite a lot of ErrSecs.  The line doesnt feel quite as laggy but theres still periods in the evening where its dropping packets and therefore still slow.  DLM detects that MBTE is still red so it increases the depth of interleaving again.

Day 3

Line A .  DLM has removed interleaving. No FECs but theres now CRCs and E/S again.  What the DLM does next depends upon its status.  If it sufficient MTBE to go back to red then the DLM will reapply the interleaving.  If its amber then the DLM wont do anything. *

Line B.  Line is still getting lots of FECs but the MTBE is still amber.  DLM doesnt care.  Error correction working as it should.  No action taken.

Line C.  Line now has level 2 Interleaving. Its getting loads of FECs, way more than line 2, but MTBE is still amber.  DLM doesnt care. Error correction is working as it should.  No action taken.   However if line continues to MTBE red, then DLM will keep applying further steps until it stays amber.


*  note re Line A.  The next time it goes MTBE red then the DLM will wait longer on the next MTBE green before removing interleaving.  This is to prevent a line continually flapping between interleaved and non interleaved. After each episode of DLM intervention the line will have to remain stable for longer before it will consider removing interleaving regardless or not if MTBE is green.


The above is a cut down version for an example to try make it simple and doesnt take account for line monitoring during the MTBE green stage...  otherwise Id be typing all night 
The main thing though is DLM isnt bothered by FECs.  Its ErrSecs that cause data to be lost and the line to drop.  Too many ErrSecs then the DLM will take action.  As long as the line stays MTBE amber then it just doesnt care. 

[jid]

Thanks Kitz. Although I assume DLM won't bring back up a banded profile like I'm on as quickly as a few days?

Caution Counters have to be green for 9 days for this to happen?

[Ixel]

Thanks Kitz. Although I assume DLM won't bring back up a banded profile like I'm on as quickly as a few days?

Caution Counters have to be green for 9 days for this to happen?

Presumably for whatever length they are, they might not necessarily be 9 days if the original algorithm that Plusnet describes is still in use. This means if you've had a previous DLM intervention then it might take a bit longer than 9 days before positive changes are made this time.

[kitz]

Im not sure where 9 days comes into it.* 

AFAIK Its supposed to work on a doubler method that I mentioned in the other big thread.  ie the first time the DLM hits it will adjust you back after 1 day green,  the next time it will take 2 days, then 4 etc.  The idea behind this is to stop lines flapping between interleaved and non-interleaved.  The recovery process is an area where I need to do a lot more digging and reading yet though.

When my line was hit by the DLM in October, it started recovery after one full day of MTBE green.   It took a few days to recover completely as it went through each reduction in turn.    I was hit quite badly with Err Secs after some changes BT made to the backhaul to the extent that I was MTBE red for several days before they fixed the fault.. so by the time they did fix it I'd got several steps to backtrack on.   But it did and each day it would move one step closer to being completely removed.

ADSLMax/Golden Fibre is another member of this forum who was hit by DLM for the first time after he was messing with a new router and he also recovered after just one full day of MTBE & MTBR green.



*Only a guess, wonder if thats the old method from years & years ago.  Ive seen people mention 9 days before, but its not in any of the documentation I've seen.   

[jid]

I'm currently 7 days from my last DLM adjustment, 8 days since the first.

Currently unable to run DSL Stats on the Super Router as the modified config file does in fact leave telnet open to the WAN.

However, I believe my old Super Router's power supply was causing noise, which led to the original issues. Currently I'm seeing no ES, however, lots and lots of FEC errors - not an issue, I don't want interleaving off.

Tempted to put the HG612 back on, but not sure if messing again will do me any help except to be able to retrieve stats. The Super Router also syncs higher than the HG612.

[kitz]

If you do,  leave the modem cable unconnected for 30 mins, so DLM sees it as an unforced retrain.