a DLM question
Thank you very much Chris. That's very helpful. 
Please take your time, I'm in no rush.
Please take your time, I'm in no rush.
Chris,
I thought you might find the following of interest: http://forums.thinkbroadband.com/fibre/4240841-dlm-fault-recovery.html?page=1#Post4240966 particularly the following extract from one of BT's DLM patents here https://data.epo.org/publication-server/pdf-document?PN=EP2342902%20EP%202342902&iDocId=7810509&iepa...
In plain English, in the absence of the (fault) conditions that gave rise to the application of a less aggressive profile, DLM (if it's current embodiment were following BT's patent) should step the line up by one more aggressive profile level every 14 days.
Elsewhere, it states
So, 1 ES every ~144sec (or 2.4mins) at 67Mb/s and no SES in the same period implies that the BER is something like 10^-10 < BER < 3.2*10^-8.
Hope this is of some use to you in your investigations.
I thought you might find the following of interest: http://forums.thinkbroadband.com/fibre/4240841-dlm-fault-recovery.html?page=1#Post4240966 particularly the following extract from one of BT's DLM patents here https://data.epo.org/publication-server/pdf-document?PN=EP2342902%20EP%202342902&iDocId=7810509&iepa...
Quote In the present embodiment, each line is processed once every 24 hours to determine how the line should be
categorised, and thus if a new profile should be selected for that line. In order to avoid frequent oscillations between
adjacent profiles, a good and a bad delay counter are used to place a delay on how quickly a line is reprofiled. Thus,
every time a line is categorised as good a good delay counter is incremented (and a poor delay counter is decremented)
and only once the good delay counter has reached a good threshold (which in the present embodiment is set to 13) is
a request made to the OSS for the profile to be increased by one step to a more aggressive level, and then the delay
counters are reset.
In plain English, in the absence of the (fault) conditions that gave rise to the application of a less aggressive profile, DLM (if it's current embodiment were following BT's patent) should step the line up by one more aggressive profile level every 14 days.
Elsewhere, it states
Quote The SNR margin represents the amount of redundancy built into the selected bit rate (and other connection
options) for the connection, given the measured value of the actual SNR experienced by the modem. Thus, each possible
set of significant values for the connection parameters (i.e. bit-rate, level of trellis coding, level of interleave, etc.) has a
corresponding baseline SNR which represents the minimum value of the SNR at which the connection would be expected
to operate with a Bit Error Rate (BER) of 10-7 (i.e. 1 bit is expected to be in error for every 10-7 bits); this BER of 10-7 is
called the target rate as the connection is expected to operate very well with this level of BER. The SNR margin represents
the amount (in decibels) by which the actual measured SNR exceeds this baseline amount at the time of setting up the
connection. Thus the actual received SNR may vary over time, after setting up the connection, below the measured
amount at setting up the connection by up to the amount of the margin and still the connection would be expected to
operate with a BER of less than or equal to the target amount (i.e. at least as good as the target amount).
So, 1 ES every ~144sec (or 2.4mins) at 67Mb/s and no SES in the same period implies that the BER is something like 10^-10 < BER < 3.2*10^-8.
Hope this is of some use to you in your investigations.
Quote from: Anotherone You missed one important quote from asbokid's post on TBB
Quote the DLM takes somewhat longer to re-profile upwards than it does to re-profile down.
Well that's true, but I think I did quote a 14day up re-profiling time, and to remind us us, my profile band has been 'stuck' now in the same band for > 6weeks, with no further DLM intervention i.e. reprofiling up or down.
Yes, there is a delay_doubler counter that is used to provide hysterisis, but this only exponentially doubles the period required to reprofile up again if it gets reprofiled down again in the interim, i.e. this is there to prevent oscillation or churn in reprofiling.
So, a one way transition down, followed by a series of one-way transitions up, should not cause delay doubling AIUI. So the basic 14 day period should determine up reprofiling (in the absence of a recurrence of problems with the line).
However, there is a clear (if understandable) bias in that it only takes 3 days in which some error condition can cause a reprofiling down, but in extremis, it could take (allegedly) as long as 2^5*14days, or ~14 months in a worse case to reprofile back up again.
All of that's if the basic framework still works as described.Yes to both.
Quote He's a very knowledgeable chap if you follow any of his posts.
Quote I'm not sure if it's right that your assumptions about BER are correct from ES & SES errors, wouldn't FEC deal with an odd Bit Error so would it actually show as an ES/CRC?
They may not be, but it is my poor attempt to quantify it. Please, anybody, feel free to correct it. However, vague as it is on the subect, I think you are right that it is (probably) counting ES/CRCs. I was given to understand by Asbokid, that you need 320/s of these to qualify as a SES. So these are the 2 bounds in my estimate: somewhere between 1 (an ES/CRC) and 320 (a SES/CRC)/s?
[EDIT] But I may well have misunderstood. This is what he told me
Quote SES must have at least 320 uncorrectable / CRC) errors in a second
Sure, I understood it was as much a question as a comment. I apologise if I gave you the impression I thought otherwise.
It just made me explain further the basis on which I have tried to put a bound on it (using my own data). As you say, the definition of ES/SES is not simplistic; moreover the description given by BT only refers to 'errors per second' (presumably unrecovered ones). So in the absence of having the code to examine, all we can do is try to make a best guess about what that means.
For example, it suggests as a mechanism that one possible criteria might be
dick:quote
I apologise if I gave you the impression I thought otherwise. It just made me explain further the basis on which I have tried to put a bound on it (using my own data). As you say, the definition of ES/SES is not simplistic; moreover the description given by BT only refers to 'errors per second' (presumably unrecovered ones). So in the absence of having the code to examine, all we can do is try to make a best guess about what that means.
For example, it suggests as a mechanism that one possible criteria might be
Of course, by error-free they mean what?
Quote to keep the line error free for 98.3% (59/60 seconds) of uptime measured over a 24
hour period
dick:quote
As you will have noticed no doubt, that when it comes to DLM there are always more questions than answers
Considering, as you mentioned earlier, your line has been stuck this way for more than 6 weeks, it certainly suggests something is broken, just hoping it's not borked completely.
Considering, as you mentioned earlier, your line has been stuck this way for more than 6 weeks, it certainly suggests something is broken, just hoping it's not borked completely.
Well, if anyone's interested, the answer in my case was a 58 days from the 'eventful' day, or 52 days of being 'stuck' on a DS profile max of 67Mb/s, depending upon how you want to look at it.
=~=~=~=~=~=~=~=~=~=~=~= log 2013.06.05 05:37:10 =~=~=~=~=~=~=~=~=~=~=~=
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 33166 Kbps, Downstream rate = 92028 Kbps
Path: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 0.0 15.2
Attn(dB): 0.0 0.0
Pwr(dBm): 12.4 2.3
VDSL2 framing
Path 0
B: 239 237
M: 1 1
T: 23 45
R: 0 16
S: 0.0955 0.3782
L: 20107 5373
D: 1 1
I: 240 127
N: 240 254
Path 0
INP: 0.00 0.00
PER: 1.64 4.25
delay: 0.00 0.00
OR: 116.56 60.17
Of course, that very day BTOR UG cable teams started working on the same D-side cable from the PCP that supplies my DP and others. They worked on it for 2 days tone-tracing pairs, rodding a new cable length and rejointing it. All the while completely oblivious to the concept of always-on DLM-monitored broadband. Fortunately on the second day I was able to power down the modem while they were working in an attempt to avoid the worst impacts. Nevertheless their work resulted in several large transient surges of CRC errors on both days. On day 3, after they had finished, I was amused to find that DLM regarded their work as REIN, imposing an interleaving depth of 1541, and an INP of 3 (8ms delay).
[Edit] for comparison, the worst interleaving depth ever experienced over the entire 2-3km D- & E-side on ADSL2+ was only 128!
So, perhaps in another 58 days, provided BTOR haven't decided to meddle again, perhaps, just perhaps, DLM might return my line back to fastpath.
=~=~=~=~=~=~=~=~=~=~=~= log 2013.06.05 05:37:10 =~=~=~=~=~=~=~=~=~=~=~=
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 33166 Kbps, Downstream rate = 92028 Kbps
Path: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 0.0 15.2
Attn(dB): 0.0 0.0
Pwr(dBm): 12.4 2.3
VDSL2 framing
Path 0
B: 239 237
M: 1 1
T: 23 45
R: 0 16
S: 0.0955 0.3782
L: 20107 5373
D: 1 1
I: 240 127
N: 240 254
Path 0
INP: 0.00 0.00
PER: 1.64 4.25
delay: 0.00 0.00
OR: 116.56 60.17
Of course, that very day BTOR UG cable teams started working on the same D-side cable from the PCP that supplies my DP and others. They worked on it for 2 days tone-tracing pairs, rodding a new cable length and rejointing it. All the while completely oblivious to the concept of always-on DLM-monitored broadband. Fortunately on the second day I was able to power down the modem while they were working in an attempt to avoid the worst impacts. Nevertheless their work resulted in several large transient surges of CRC errors on both days. On day 3, after they had finished, I was amused to find that DLM regarded their work as REIN, imposing an interleaving depth of 1541, and an INP of 3 (8ms delay).
[Edit] for comparison, the worst interleaving depth ever experienced over the entire 2-3km D- & E-side on ADSL2+ was only 128!
So, perhaps in another 58 days, provided BTOR haven't decided to meddle again, perhaps, just perhaps, DLM might return my line back to fastpath.
Yes. That was on Day 1 after the previous 52 days, before BTOR UG arrived. 
[Edit] This is what they look like now:
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 33974 Kbps, Downstream rate = 92152 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 78750 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.3 15.1
Attn(dB): 0.0 0.0
Pwr(dBm): 12.4 2.9
VDSL2 framing
Bearer 0
MSGc: 14 26
B: 51 237
M: 1 1
T: 64 45
R: 12 16
S: 0.0210 0.3782
L: 24362 5373
D: 1541 1
I: 64 127
N: 64 254
Bearer 0
INP: 3.00 0.00
INPRein: 0 0
delay: 8 0
PER: 1.34 4.25
OR: 118.95 60.17
[Edit] This is what they look like now:
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 33974 Kbps, Downstream rate = 92152 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 78750 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.3 15.1
Attn(dB): 0.0 0.0
Pwr(dBm): 12.4 2.9
VDSL2 framing
Bearer 0
MSGc: 14 26
B: 51 237
M: 1 1
T: 64 45
R: 12 16
S: 0.0210 0.3782
L: 24362 5373
D: 1541 1
I: 64 127
N: 64 254
Bearer 0
INP: 3.00 0.00
INPRein: 0 0
delay: 8 0
PER: 1.34 4.25
OR: 118.95 60.17
