Showing results for 
Show  only  | Search instead for 
Did you mean: 
Message 21 of 34

Re: Yes. That's where I can see the stats from. See below :-

@greglloyd wrote:

Yes, I understand that DLM is adjusting to give the best under the circumstances but it changed from 6db to 10db margin almost two months ago. The issue could have long since resolved itself but the DLM has not bothered to go back to 6db. My line has always beeen 6db target margin since I got infinity.


DLM uses logic, not attitude, on whether changes are necessary.


With ADSL the DLM system was well understood. Target SNR margin changes would take place exactly 7 days after stable line performance with BRAS profile then following 3 days later. With VDSL2 it is not clear when target margin changes take place and nobody seems to have a clue.


DLM on the EU metallic path twixt DSLAM and NTE is much like ADSL2+, with line control using SNRm, interleave and banded profiles ... to stabilise the connection.


It would be great to have clarity about when exactly the system makes a target SNR change (we know that the IP profile changes instantly when you get a new sync speed). Because it's very clear that it's not the same as ADSL. I've had my modem connected continuously for weeks and can tell from the modem logs that the cabinet has not forced my modem to resync at ANY stage. So it's not like the DLM system has continued to monitor and decided to resync me at the same 10db SNR margin because it has detected continuing issues with the line.


Recovery will be based on time/noise margin rate thresholds, as is ADSL2+ ... in other words it has to see "benchmarks" or levels of improvement over set time periods to permit a shift.


With ADSL there were very clear timescales for changes (and yes, I do understand this is a different technology and the rules are different. I work as an IT professional and fully understand this). I just want to know if anyone has worked out the rules. I know the docs saying DLM is continuous on VDSL2 but that appears to be continuous and immediate drops in speed if line issues appear. It is most definitely not continuous monitoring for bumping the speed back up again.


The probable reason that it seems to take an age to repair is simply down to the fact that the very high frequencies employed in the VDSL transmission are much harder to bitload, as against ADSLmax for instance, simply because of the bit rates needed to sustain the modulation. Even ADSL2+ because it uses higher frequencies is a challenge compared to ADSLmax. VDSL is no different. (in fact probably a tad worse)



To add to the above ... troublesome ADSL2 and 2+ profiles are put into "catergories" ... colour bands in fact, on paper, if you were to print one out from the BT diagnostics. DLM is bi-directional, up and down. When a line is stable and met its MSR ... the MSAN will pulse the line once every 24 hours to "check it". It will also run a continuous algorithm to adjust SNRm 24/7. If a line breaches error rate thesholds and drops the connection, DLM will "up" its attention span from one diagnostic pulse to several in the 24 hour period, depending on the level of shift (away from the MSR). That is why established line history is paramount with DSL, simply because when DLM does change its mode, it sets its diagnostic procedure on the past history, its last MSR and the amount of shift it is "seeing" that has caused a resync, or loss of connection. It uses various levels of change to the line, with interleave depth and changes in noise margin, either collectively or singularly depending on the rate of "mend" required to get it to the last best MSR. If a line improves, logic will check how long it took to improve, and the level of improvement, to adjust the margin rates and slacken off on error correction depths to allow the fastest possible linespeed. All the changes used are done by logic alone, from set scenarios and levels of shift, away from MSR.


VDSL is no different .... but uses higher frequencies to modulate the bitstream ... and thus will be more troublesome to "repair" ... for the line condition. And when you take into account that the DLM has to see improvements on such connections, given the frequency issues .... it's really no wonder it takes longer.


Hope this helps.    🙂

0 Ratings
Message 22 of 34

Re: Yes. That's where I can see the stats from. See below :-

As an additive to the above, and just for clarification.


DLM does not REPAIR connections .... to the best connection you ever had.


It STABILISES connections ... to achieve the best MSR possible for the line condition.


Also worth remembering ... is that when you first have the product, it trains using WIDE OPEN PROFILES


in an attempt to get the best linespeed possible ... but after training, and once it has run its basic line training period


DLM takes over, as described above .... and the subtlties of changes in margin and linspeed become apparent as the


product establishes itself on the connection, with one thing in mind ... true stability, and the maximum stable rate.


It continues then 24/7/365 .... and adjusts accordingly to the line condition, using complex algorithms as basically



0 Ratings
Aspiring Expert
Message 23 of 34

Re: Yes. That's where I can see the stats from. See below :-

Thanks Roger. Nice write up.


But just to your last point, the thing is my SNR is very very stable and my speed has consistently been at 39999/9997 for the first year and 42000/9850 for a second full year (far beyond the training period). When it was at 6db is never veered from this figure by more than 0.1db either side. At 10db it also is not veering by any more than 0.1db either side. The sync speed is also exactly 34996 ever single time it is resync'd (on purpose). Though I avoid reboot the modem at all costs obviously to avoid the DLM misinterpreting it as line issues.


This drop in speed came after I change to option 1 and back again.


Anyway, thanks guys for the info


Here is the current picture for my line taken today :-


# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 9813 Kbps, Downstream rate = 43180 Kbps
Path: 0, Upstream rate = 9809 Kbps, Downstream rate = 34996 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 10.0 6.3
Attn(dB): 0.0 0.0
Pwr(dBm): 12.8 5.0
VDSL2 framing
Path 0
B: 239 237
M: 1 1
T: 64 41
R: 0 16
S: 0.2183 0.7709
L: 8797 2636
😧 1 1
I: 240 127
N: 240 254
Path 0
OHF: 29333316 275207
OHFErr: 778 24
RS: 0 942437
RSCorr: 0 66
RSUnCorr: 0 0

Path 0
HEC: 1949 0
OCD: 0 0
LCD: 0 0
Total Cells: 2619584270 0
Data Cells: 74203991 0
Drop Cells: 0
Bit Errors: 0 0

ES: 535 17
SES: 0 0
UAS: 17 17
AS: 102838

Path 0
INP: 0.00 0.00
PER: 3.49 7.90
delay: 0.00 0.00
OR: 54.98 32.39

Bitswap: 2440 12039

0 Ratings
Aspiring Expert
Message 24 of 34

Re: Yes. That's where I can see the stats from. See below :-

One thing to add is that my error counts at 42 meg were probably in the tens of thousands over the period of a month. So I suspect that possibly the DLM has cut the speed back to 35 meg to reduce this number of errors. Of course this is for BT / Openreach's benefit rather than mine. It saves them bandwidth by avoiding dropped packets. From my point of view the higher speed was a better experience for me and I saw no stablility issues. So, even though it is 'technically' a more stable line from the DLM point of view - this benefits BT and not me I would say.

0 Ratings
Message 25 of 34

Re: Yes. That's where I can see the stats from. See below :-

The purist would argue .... no, it benefits the NETWORK 🙂

There's a difference. 😉
0 Ratings
Aspiring Expert
Message 26 of 34

Re: Yes. That's where I can see the stats from. See below :-

You are absolutely correct of course 🙂

0 Ratings
Message 27 of 34

Re: Yes. That's where I can see the stats from. See below :-

I do have a theory Greg why things are as they are .... but I am guessing, although it might be plausible.


At the outset when you first had the product .... your linespeed would have been set as per the scenario I spoke of ...


that is ... with a wide open profile based DLM mode. When you shifted across the broadband options, even though you'd


already got the product, BT may (I don't know though) have a system that checks to see if the product does or has


existed already on that line. And if so .... sets the DLM line parameters from line history, rather than from a day 0 line


training profile. In which case may account for some apparent loss of linespeed. (as it "knows" it's already trained on the


line already) .... as i said, it's a guess. But plausible.  I can't think of any other scenario.  🙂

0 Ratings
Distinguished Expert
Message 28 of 34

Re: Yes. That's where I can see the stats from. See below :-

it may be possible for you use use the graphing scripts that have been developed for the hg612 so you can get more insite into the errors that dlm may be seeing on your line
are you still getting those smurf entries in the logs that you were seeing before?
0 Ratings
Aspiring Expert
Message 29 of 34

Re: Yes. That's where I can see the stats from. See below :-

Hi Roger,


I've actually transitioned between product on two different occasions in the past. Each time you switch product the profiles are set back to wide open on day one. However, I would not be able to switch product again as BT have now changed the system so that you cannot downgrade to Option 1 when you are within the new contract period for Option 2 (whereas before you could).


0 Ratings
Aspiring Expert
Message 30 of 34

Re: Yes. That's where I can see the stats from. See below :-

Hi Bullit,


No, no smurf attacks lately. Here are the latest log entries. Note that the DSL activate entries are from intentional modem reboots. You can see frmo the logs that the modem has been up continuously with no resync for 22 days :-


Manufacturer:Huawei Technologies Co., Ltd.
Style:EchoLife HG612
SW Ver:V100R001C01B028SP10

2000-1-2 23:23:9 Notice 0 admin login
2000-1-1 0:0:23 Notice 0 admin login
2000-1-1 0:0:21 Notice 104500 DSL activate succeed
2000-1-1 0:0:17 Debug 104500 LAN1 up
2000-1-1 0:0:15 Debug 104500 LAN2 up
2000-1-1 0:0:14 Notice 1 System up
2000-1-1 0:0:3 Warning 10400 KLOB Pool 1 Initialized: 1048576 bytes <0x80300000 ... 0x80400000>
2000-1-22 0:35:32 Warning 104001 System reboot
2000-1-22 0:35:4 Notice 0 admin login
2000-1-21 11:3:51 Notice 0 admin login
2000-1-19 0:5:11 Notice 0 admin login
2000-1-17 23:39:21 Notice 0 admin login
2000-1-17 2:1:48 Notice 0 admin login
2000-1-16 8:46:13 Notice 0 admin login
2000-1-15 1:26:48 Notice 0 admin login
2000-1-13 15:32:25 Notice 0 admin login
2000-1-11 23:22:23 Notice 0 admin login
2000-1-11 23:21:51 Notice 0 admin login
2000-1-11 23:20:19 Notice 0 admin login
2000-1-11 23:13:0 Notice 0 admin login
2000-1-10 0:33:57 Notice 0 admin login
2000-1-9 0:16:48 Notice 0 admin login
2000-1-8 0:24:12 Notice 0 admin login
2000-1-7 9:34:9 Notice 0 admin login
2000-1-5 8:46:51 Notice 0 admin login
2000-1-3 10:12:19 Notice 0 admin login
2000-1-2 2:12:6 Notice 0 admin login
2000-1-1 9:47:48 Notice 0 admin login
2000-1-1 0:0:48 Notice 0 admin login
2000-1-1 0:0:22 Notice 104500 DSL activate succeed
2000-1-1 0:0:17 Debug 104500 LAN1 up
2000-1-1 0:0:14 Debug 104500 LAN2 up
2000-1-1 0:0:14 Notice 1 System up

0 Ratings