Print

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

[Dray]

Fair enough...what then are the criteria for keeping interleaving on if not ES?

ES and resyncs, I think.

[strontium90]

ES = Zero,
Resync = Uptime 42 days..

Maybe DLM just doesn't like me?

[les-70]

  Assuming that your strontium on MDWS then you have about 10-30 ES/day which you would think is enough to get fast path?? If it is any consolation others have similar stats and the same issue.  Kitz has suggested it may be some long past line history which is being remembered in such cases.

[strontium90]

Thanks les-70...It does seem I am being punished for something I am not aware of...does anyone else agree that DLM is far too slow to react to stability an d surely the algorithm needs modification?

[Chrysalis]

I didnt check the site as I am way too busy today, so les has confirmed your ES is not 0.

The daily ES threshold we have discussed here is far from confirmed, we just been posting guess's based on documents found on the internet and people's experiences.

All I can say is when DLM moved me back to fast path in the past my ES was either 0 or extremely low, maybe 1-2 per day at the most.

[tbailey2]

If it's of any help at all, I've been off and on fastpath twice in the past 4 months (currently on fast).

Here is the graph that shows the total ES since 1st August to today. Bit difficult to read but it might show something. The highest value when interleaved is about 138. I think you can see what put it back on interleaved most recently...

Note that you can't generate this graph yourself for that period of time as I frigged the code to do it locally on my home server, hence why it says 48hrs...

Edit:

Added BE1's since 1st Jan - interesting!!

[Black Sheep]

  Assuming that your strontium on MDWS then you have about 10-30 ES/day which you would think is enough to get fast path?? If it is any consolation others have similar stats and the same issue.  Kitz has suggested it may be some long past line history which is being remembered in such cases.

Possibly ?? Taken from ADSL DLM docs, may also apply to VDSL ??

1) A lines performance history is considered by DLM
2) DLM learns from the actions it has taken in the past to influence the actions it will take in the future
3) For example if interleaving has been removed from a line and it becomes unstable, DLM will wait longer next time before taking the same action

[kitz]

Thanks BS.  Yep thats the one.  Its one of the DLM processes. 

Both ADSL and FTTC use the same DLM system and both have exactly the same DLM processes and functions.  They may however have different parameters.

For example with adsl the speed/standard profile MTBE params are [5,250] yet for FTTC they may not yet have been updated and may still be [30,300]

Another example of a parameter difference is configuration of the DLM profile: On ADSL1 its simply [Interleaving, SNRm] ADSL2+ its [Interleaving, INP, SNRm] and on FTTC its [Interleaving, INP, Banding].  The process how it decides something needs changing and how it implements it though is the same.


Edit MTBE typo

[les-70]

  While the DLM parameter changes may have altered starmans 4000+ ES for a few days now puzzle me.  I wondered whether, if work is done on a line and things are reset, whether the DLM does not go into action until the job is logged as complete.  I had a week or so after my FTTC install with Openreach trying to rebook appointments to do the install even though it was done.  I was told by TT that until the engineer signed it off the DLM actions would  not start as the system did not count me as connected. Maybe BS can comment.

[NewtronStar]

3) For example if interleaving has been removed from a line and it becomes unstable, DLM will wait longer next time before taking the same action[/b][/i]

What if like me there is no history this line has never been moved off interleave from the very first day on FTTC over 3 years now, though can't be 100% sure as I didnt have the HG612 unlocked to monitor stats on activation day but the pings were around 25ms.

[NewtronStar]

All I can say is when DLM moved me back to fast path in the past my ES was either 0 or extremely low, maybe 1-2 per day at the most.

If thats the case then capping wy line was a waste of time as I my errored seconds have dropped but know way near close to 0 or 1-2 per day more like 70 a day 

[kitz]

FWIW, Asbokid provided the following resync reasons quite a long time ago.
I think the information was geared mainly to VDSL2 connections, but I'm not 100% sure:-

Thanks BE.   Unfortunately though, I can confirm that although our modems may record those codes, and that they may be logged in the OSS.  As far as DLM process is concerned it doesnt take a blind bit of notice of any of those codes and it has its own system which it uses to detect wide area events (thunder storms) & unforced retrains (those done by the user), which is all logged by the Element Managers.

It is able to differentiate between instability due to retrains and those due to Errors, and it does keeps a permanent record of whether DLM intervention was due to retrains or errors.

Still in draft format but explanation of how it calculates these are described in Detection of sync events and further depth Unforced retrains and Wide area events

I make no apologies for how long this is taking me to put together.  I stress that my information hasnt come from BS, but I think he may be one of the few who will be able to see and appreciate how hard it is to separate the wheat from the chaff in all the information that is available.  Ive literally spent what must now amount to several hundred hours trying to pick meat from the bones, just to get at the stuff we are interested in.    The subject is HUUUUUUUUUUUUGE.   I never realised what a mammoth task this was going to be

[burakkucat]

N*Star, I can assure you that for the very first 24 hours after the installation, your line will have been configured "wide open" on fast-path. It would have been from the second day onwards that the DLM system would have taken an interest in the line (and then only if it had just cause to do so).

[kitz]

  While the DLM parameter changes may have altered starmans 4000+ ES for a few days now puzzle me.  I wondered whether, if work is done on a line and things are reset, whether the DLM does not go into action until the job is logged as complete.  I had a week or so after my FTTC install with Openreach trying to rebook appointments to do the install even though it was done.  I was told by TT that until the engineer signed it off the DLM actions would  not start as the system did not count me as connected. Maybe BS can comment.

You may have a point there les.  I know when I had a line fault the other month, my ISP kept saying that there was certain information they couldn't access about my line, because the fault was still open with BT and not yet signed off.

[Black Sheep]

  While the DLM parameter changes may have altered starmans 4000+ ES for a few days now puzzle me.  I wondered whether, if work is done on a line and things are reset, whether the DLM does not go into action until the job is logged as complete.   I had a week or so after my FTTC install with Openreach trying to rebook appointments to do the install even though it was done.  I was told by TT that until the engineer signed it off the DLM actions would  not start as the system did not count me as connected. Maybe BS can comment.

I have no idea about when DLM triggers on new installs, I'm afraid.

But the comment I've highlighted above suggests repair-type work, of which the DLM goes into action the moment it's been re-calc'd (reset). Our processes tell us only to reset if a fault has been located, but (as I've said many times), I tend to do one before I even get to site in order that I can see the full error-rate without it being masked. I will apply the caveat that I do view the circuits history before doing this, so I have an understanding of previous behaviours. 

In short, the job does not have to be signed off on repair work for DLM to be triggered.