Print

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

[kitz]

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).

I can confirm this.   Although I did see something that implied it may be 2 days - ie install day + one full day.   Be damned if I can find it now though to go back and check ..  but for sure everyone starts off with the wide open profile and interleaving wont have been added right from the start.

[burakkucat]

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.

I should have commented right after B*E1 made that post. The information quoted is from a header file to the Broadcom driver code. It is only used within the driver and is, essentially, decoupled from the "external, real world situation".

Edited to add:

Not the file for which I was actually looking but I managed to "put my paws" on one that contained the following section of code --

Code: [Select]

/*  line-drop reason code */
#define kRetrainReasonLosDetector                   0
#define kRetrainReasonRdiDetector                   1
#define kRetrainReasonNegativeMargin                2
#define kRetrainReasonTooManyUsFEC                  3
#define kRetrainReasonCReverb1Misdetection          4
#define kRetrainReasonTeqDsp                        5
#define kRetrainReasonAnsiTonePowerChange           6
#define kRetrainReasonIfftSizeChange                7
#define kRetrainReasonRackChange                    8
#define kRetrainReasonVendorIdSync                  9
#define kRetrainReasonTargetMarginSync             10
#define kRetrainReasonToneOrderingException        11
#define kRetrainReasonCommandHandler               12
#define kRetrainReasonDslStartPhysicalLayerCmd     13
#define kRetrainReasonUnknown                      14
#define kRetrainReasonG992Failure                  15
#define kRetrainReasonSes                          16
#define kRetrainReasonCoMinMargin                  17

Note the section-header comment: /*  line-drop reason code */

[NewtronStar]

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).

Good point B*CAT the 2 day wide open connection, We could give Oprenreach a call and say there is a fault could you come out and check the line and while your at it reset it for me and I make the best tea/coffee in the UK.
 

[burakkucat]

. . . I make the best tea/coffee in the UK.

Not forgetting the fresh cat-mint and kitteh treats! 

[kitz]

Ok, thats it from me for today as far as DLM is concerned, Ive spent all day sat at the PC reading white papers and docs and other stuff thats made my head hurt - not to mention a numb bum.    Im done in and off to watch some TV curled up comfy on the sofa with the kittehs.

Enjoy your tea/coffee/wine/cat-mint everyone.

[les-70]

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...
Added BE1's since 1st Jan - interesting!!

   Thanks for those, as you say very interesting. Yours shows clear behavior but it is odd that all the excursions above 1440 go also well above 2880 and don't reveal just what errors may be needed.  BE1's has some odd events.  It bothers me that over those time periods all of the big error values could have been due to thunderstorms - indeed surely some must be- yet all except one of BE!'s were acted upon.   It looks like the errors get very low before a recover from interleaving -- any idea how low?

  However maybe RAMbo is dead or changing now.

[Chrysalis]

here is why he not been DLM'd with the high ES, mystery solved

http://www.thinkbroadband.com/news/6726-assia-court-case-forces-openreach-to-turn-off-dlm.html

I guess you stuck newt

[kitz]

It bothers me that over those time periods all of the big error values could have been due to thunderstorms - indeed surely some must be- yet all except one of BE!'s were acted upon.

several times over the past few months Ive inferred how the DLM detects wide area events, I even put a link yesterday which describes it in more detail including the algorithm. 

the element manager also produces an event data file which is used to monitor for Wide Area Events and forced retrains.  This event data is recorded as an array of each 15 min period in binary format [Uptime, Retrains, Errors]. For example a line which has uptime and errors but no retrains will record [1,0,1].

Check for Wide Area Events

    Each day, the DLM Management Device receives sets of data from the DSLAM's element manager. First it will analyse the event data from all lines to check for events such as thunderstorms which may have caused multiple lines to resync and/or generate lots of errors.

    If a pre-determined percentage of lines experience retrains and errors in the the same time frame then any events occurring in that time frame will be classed as a Wide Area Event.

    Documentation would suggest that the percentage values for wide area events are: >20% of users with uptime experienced a resync OR  >50% of users with uptime experiencing errors && >10% of users with uptime experienced a resync.

    So attempting to put it in simple terms, if data in the binary file in any of the 15 min bins at the same time frame meets any one of the following two criteria:

        > 20% of bins are [1,1,1] OR [1,1,0]
        > 50% of bins are [1,0,1] AND >10% of bins are [1,1,1]||[1,1,0]

    then a wide area event is declared for that period. Data from any bin within the corresponding time frame is discarded and not used for the DLM calculation.

[les-70]

  I am aware that, which is why I am puzzled that all of the high ES event but one of BE1's were acted upon.  Over the time spans involved I would have expected more high ES due to e.g. thundersorms that were not acted upon. I think there is strong hint in those traces that wide area events are not well dealt with.  I wonder if it is high ES events that are not quite bad enough to give many resyncs over the "wide area" that cause some of the interleaving transitions in the plots. It might be better if the criteria was simply 50% of lines had errors without a further check on more than 10% getting resyncs.  You would need more examples to be sure.

[kitz]

This is 100% definite.
Typical that the info comes a bit too late   but here are some of the answers anyhow for the FTTC DLM.

The BToR DLM measures the following parameters:

Total 24hr SES (downstream)
Total 24hr ES (downstream)
Total 24hr SES (upstream)
Total 24hr ES (upstream)
Total 24hr uptime
Total 24hr unforced retrain count
Total 24hr Full Initialisations
Total 24hr failed initialisations
Line rate (downstream) in previous 24hr period
Minimum line rate (downstream) in previous 24hr period
Maximum line rate (downstream)  in previous 24hr period
Line rate (upstream) in previous 24hr period
Minimum line rate (upstream) in previous 24hr period
Maximum line rate (upstream)  in previous 24hr period

The days monitoring file covers the period 00:00 to 23:59:59

Definitely no FECs

[Ixel]

This is 100% definite.
Typical that the info comes a bit too late   but here are some of the answers anyhow for the FTTC DLM.

The BToR DLM measures the following parameters:

Total 24hr SES (downstream)
Total 24hr ES (downstream)
Total 24hr SES (upstream)
Total 24hr ES (upstream)
Total 24hr uptime
Total 24hr unforced retrain count
Total 24hr Full Initialisations
Total 24hr failed initialisations
Line rate (downstream) in previous 24hr period
Minimum line rate (downstream) in previous 24hr period
Maximum line rate (downstream)  in previous 24hr period
Line rate (upstream) in previous 24hr period
Minimum line rate (upstream) in previous 24hr period
Maximum line rate (upstream)  in previous 24hr period

The days monitoring file covers the period 00:00 to 23:59:59

Definitely no FECs

That's good to know. If FTTC DLM is uneffected by the ASSIA patents (and just BT's ADSL DLM which is effected) then that will continue to apply. Has anyone been able to confirm if FTTC DLM is still operational?

[kitz]

Its not the ADSL DLM that is the problem, its the FTTC DLM one, I'll make a post in a few mins in the other thread.

[Ixel]

Its not the ADSL DLM that is the problem, its the FTTC DLM one, I'll make a post in a few mins in the other thread.

Ok, thanks for confirming .

[NewtronStar]

here is why he not been DLM'd with the high ES, mystery solved

http://www.thinkbroadband.com/news/6726-assia-court-case-forces-openreach-to-turn-off-dlm.html

I guess you stuck newt

Have a feeling that the last part of your post is for me 

Then should one give up on the sync capping as it seems futile after reading your TBB link.

[les-70]

 @kitz Any idea how SES are used?  They provide a measure of the frequency of high CRC events