Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: FTTC Weird DLM Situation  (Read 575 times)

scott1989uk

  • Just arrived
  • *
  • Posts: 9
FTTC Weird DLM Situation
« on: May 20, 2019, 07:25:54 PM »

Hi everyone!

Cabinet: eci
Modem: vmg1312-b10a
Router: Q hub in wanoe mode

Sorry this is a long one, Iím after some advice / thoughts on this as itís confusing me greatly vs past experiences with fttc and dlm... I can post the stats later on but just away from home right now.

So I spent 16months on PN without dlm intervention. The line went from 74mbps, to 71mbps at Christmas, 66mbps in March and finally 59mbps in April. I had several openreach engineers out and they changed pairs, changed master socket etc... eventually they managed to get it above handback threshold at 64mbps. Throughout these speed drops, it was not due to dlm in any way; the testing on the line showed minimal interfence and no crosstalk (affecting service). OR didnít really know why it would have dropped.

Fast forward a bit and more issues with PN resulted in my leaving my contract and switching back to sky (as I had no issues before on Fibre Pro). Day of activation, my modem reported 60.8mbps connection but dlm was active (immediately) and my max attainable was 72mbps. I was under the impression there is no training period on fttc, it should be fastest out the gate and drops if necessary (based on every changeover before - unless something changed recently).

Engineer came out as it was below handback threshold, changed the pair again, speed dropped but he said he expected line to recover. Max attainable at that point showed as 69mbps on my modem. Next day, speed dropped to 50mbps and dlm had increased the depth and interleaving; and applied dlm to upstream for first time ever on my line. Called sky back up and they sent out a repeat job to OR.

The next engineer came, said it could be a lazy port so changed my fibre port on cabinet. On resync my modem again was connected at 51mbps but attainable was 74mbps. I asked him to do a dlm reset and he said wonít make a difference...

The OR kit device they use to test the line showed it as 51mbps connection, 51mbps max attainable (like dlm wasnít active). He did the reset on my request and it jumped to 68mbps (with no dlm) and the engineer was a tad surprised.

Last night, at 1am my line resyncd and again dlm was active, interleaving 8 inp 3, d:1217 or something. Connection now shows as 62mbps with an attainable of 74mbps again. 1 LOS, 8 LOF and < 600 ES errors yesterday; so not enough to trigger dlm intervention afaik? No reboots on the kit etc at all and was online for the full 96bins...

My SNR now with dlm on the line is 6.3db, same as it is when dlm is not active; so my downstream snr has not increased as I expect it to with dlm active?? This happened on the activation day too, but according to everyone remotely my line is at max speed and they donít see the dlm intervention on the line; yet locally it tells me 74mbps attainable (and on dlm reset, it was 68mbps).

Anyone experienced anything like this before (snr not increasing with dlm active, etc.)?

In the past, most de-dlm resyncs happened at 4am-5am and activate dlm resyncs happened at 11am-12am; so 1am resync is strange for me too... Sky are also unable to read the line speed from my router and have to use a different system to get it; not sure if thatís related to using the modem in the mix or not; but I donít want to disconnect it to test it with dlm active as I want to keep an eye on whatís happening.

Also, my line always used to sync higher with the PN HH5a (lantiq to eci cab). Since the switch the Broadcom based units sync faster than lantiq (tested using an old eci modem). Something just donít feel right here 🤯
« Last Edit: May 20, 2019, 07:40:40 PM by scott1989uk »
Logged

scott1989uk

  • Just arrived
  • *
  • Posts: 9
Re: FTTC Weird DLM Situation
« Reply #1 on: May 20, 2019, 07:52:35 PM »

Just a thought, if there is a training period... could dlm feel it got robbed by being reset within the first 10 days (on day 9) and it restarted training again?
Logged

scott1989uk

  • Just arrived
  • *
  • Posts: 9
Re: FTTC Weird DLM Situation
« Reply #2 on: May 20, 2019, 08:03:59 PM »

Line stats -

Code: [Select]
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:    1
Last initialization procedure status:   0
Max:    Upstream rate = 23842 Kbps, Downstream rate = 74140 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 62174 Kbps

Link Power State:       L0
Mode:                   VDSL2 Annex B
VDSL2 Profile:          Profile 17a
TPS-TC:                 PTM Mode(0x0)
Trellis:                U:ON /D:ON
Line Status:            No Defect
Training Status:        Showtime
                Down            Up
SNR (dB):        6.3             6.7
Attn(dB):        13.1            0.0
Pwr(dBm):       -0.2            -0.2

                        VDSL2 framing
                        Bearer 0
MSGc:           18              150
B:              51              236
M:              1               1
T:              64              5
R:              12              16
S:              0.0266          0.3771
L:              19240           5410
D:              1217            1
I:              64              255
N:              64              255

                        Counters
                        Bearer 0
OHF:            39536276                81679
OHFErr:         0               33
RS:             1531203788              4165672
RSCorr:         20356           2981
RSUnCorr:       0               0

                        Bearer 0
HEC:            0               0
OCD:            0               0
LCD:            0               0
Total Cells:    3787464045              0
Data Cells:     30260587                0
Drop Cells:     0
Bit Errors:     0               0

ES:             866             104
SES:            10              0
UAS:            64              54
AS:             67611

                        Bearer 0
INP:            3.00            0.00
INPRein:        0.00            0.00
delay:          8               0
PER:            1.70            6.15
OR:             112.29          202.87
AgR:            62286.69        20203.27

Bitswap:        1085/1085               4/4

Total time = 2 days 17 hours 20 min 22 sec
FEC:            20356           2981
CRC:            0               33
ES:             866             104
SES:            10              0
UAS:            64              54
LOS:            1               0
LOF:            7               0
LOM:            0               0
Latest 15 minutes time = 5 min 22 sec
FEC:            60              0
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Previous 15 minutes time = 15 min 0 sec
FEC:            94              9
CRC:            0               1
ES:             0               1
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Latest 1 day time = 17 hours 20 min 22 sec
FEC:            18175           1767
CRC:            0               19
ES:             0               17
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Previous 1 day time = 24 hours 0 sec
FEC:            2181            1214
CRC:            0               14
ES:             477             62
SES:            10              0
UAS:            37              27
LOS:            1               0
LOF:            7               0
LOM:            0               0
Since Link time = 18 hours 46 min 49 sec
FEC:            20356           2981
CRC:            0               33
ES:             0               26
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 27173
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: FTTC Weird DLM Situation
« Reply #3 on: May 20, 2019, 08:14:23 PM »

There is no "training period" for a VDSL2 (ITU-T G.993.2) based service in the UK.

If the two ends of a VDSL2 circuit (VTC-C and VTC-R, i.e. the DSLAM and the CPE modem) have been in synchronism for 24 hours following the circuit's provision, the DLM process will start to monitor the circuit and take action, if that monitoring observes sub-optimal circuit performance.

The precise details are stated in BT SIN498, Section 2.2.1 --

2.2 User Network Interface - General

2.2.1 Dynamic Line Management

Dynamic Line Management (DLM) is employed in GEA-FTTC. DLM constantly
manages lines to maintain a target link quality (speed and stability). It does this for as
long as the product exists.

At provision, the line is put on ďwide openĒ VDSL2 line profiles allowing the
upstream and downstream line speeds to run at the upper limit of the product option
selected.

On the first day of operation, DLM will intervene if severe instability is detected.
Otherwise, DLM will wait until the day after provision before deciding if it must
intervene, provided that the line has been trained up for at least 15 minutes during the
preceding day.

If DLM intervenes it will set a profile with a maximum rate and a minimum rate,
where the minimum rate is set at approximately half of the maximum rate. The
purpose of the minimum rate is to ensure that the line does not train at a rate which is
significantly below the level the line should be able to achieve. If this happened, then
the line is likely to remain at a very low rate until a re-train is forced by the user by
powering off the modem.

Note : It is the DLM system that sets the line profile, and this should not be interfered
with by CPs/users setting rates, SNR margins etc. at the modem.

Note : The upstream throughput is also constrained on the DSLAM to the upstream
rate requested in the order, i.e. 2 Mbit/s, 10 Mbit/s or 20 Mbit/s, so even if the VDSL2
upstream line speed is higher, the upstream throughput is constrained to the level
ordered for the product.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

scott1989uk

  • Just arrived
  • *
  • Posts: 9
Re: FTTC Weird DLM Situation
« Reply #4 on: May 20, 2019, 10:10:20 PM »

Thanks, thatís exactly how I thought it worked!

So if I had dlm action on activation day, according to sin498 thatís impossible, so I wonder why it happened?

Plus, the SNR has not increased when dlm has intervened which is weird and it threw me in the sin bin for no reason today; as those stats arenít above 1440 es per day and there was 0 resyncs.

I have no idea how to explain this to sky, who will run a line test and say everything is okay again; but something isnít right somewhere clearly... Iíll have to ask for a tech support manager I guess and try to get them to investigate it.

Problem is, even the openreach engineer didnít think dlm was active due to his kit saying max attainable and connection rate was very similar; nightmare!
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 27173
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: FTTC Weird DLM Situation
« Reply #5 on: May 20, 2019, 10:38:15 PM »

So if I had dlm action on activation day, according to sin498 thatís impossible, so I wonder why it happened?

No, it's not impossible . . . It is possible. The first sentence of the third paragraph, of section 2.2.1, of BT SIN498, states --

On the first day of operation, DLM will intervene if severe instability is detected.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

scott1989uk

  • Just arrived
  • *
  • Posts: 9
Re: FTTC Weird DLM Situation
« Reply #6 on: May 21, 2019, 12:07:06 AM »

Yeah thatís fair enough but I checked it just after the sync light went back solid (following disconnection for change over) and the stats showed dlm intervention immediately?
Logged

j0hn

  • Kitizen
  • ****
  • Posts: 2553
Re: FTTC Weird DLM Situation
« Reply #7 on: May 21, 2019, 12:58:43 AM »

The default line profile is now Low Interleaving.

It used to be fastpath (no INP/Interleaving) by default and only after exceeding the error threshold would DLM take action on the line.

All lines on ECI cabinets now start with Low Interleaving and will only change to fastpath if stable enough.
This is the case for new lines, migrations and DLM resets.

Lines connected to Huawei cabinets also default to Low Interleaving but they have G.INP applied after a short period of time (usually 2 days).

There is indeed no training period on FTTC.

Quote
At provision, the line is put on ďwide openĒ VDSL2 line profiles allowing the
upstream and downstream line speeds to run at the upper limit of the product option
selected.

My interpretation of "Wide Open" was always that it meant fastpath (no error protection at all).
Others argue that it simply means the line is uncapped.

The drops in sync over time that you have detailed above sound like typical examples of crosstalk. It's the consequence of other lines being activated for FTTC on your cabinet.
Most users on FTTC lose some sync speed due to crosstalk. Some lose much more than you and others a little less.
Logged
Plusnet FTTC 80/20 -  ECI now Huawei cab
retx low @ 3dB target SNRM
Zyxel VMG1312-B10A bridged with 1508 MTU + Asus RT-AC68U running Asuswrt-Merlin

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 32147
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: FTTC Weird DLM Situation
« Reply #8 on: May 21, 2019, 10:46:46 AM »

Quote
My interpretation of "Wide Open" was always that it meant fastpath (no error protection at all).

Correct.  Wide Open certainly used to be the term used by Openreach to describe  "up to" 48hr period without any error protection or line cap after provision of a new line.  The line would also enter the Wide Open profile after an Openreach Engineer's reset of the line.

However, as you say since last year even DLM resets performed by Openreach Engineers now by default use low interleave.

Quote
Throughout these speed drops, it was not due to dlm in any way; the testing on the line showed minimal interfence and no crosstalk (affecting service).

I agree with J0hn, those speed drops do indeed look most likely down to crosstalk.  The thing is crosstalk is a constant (except if the disturbers modem is switched off) and since there isn't anything that Openreach can do about it, it is classed as not affecting service :(

My own line has gone from a max attainable of 110Mbps down to 64Mbps purely through crosstalk.   Unfortunately nothing can be done - each time a new neighbour gets vdsl, my own line rate decreases further.    :'(

Quote
INP:            3.00            0.00

Your line currently has low interleave set.   This will artificially inflate the Max attainable speed reported by your modem.   
It is a known issue that when the line has RS error correction applied that it will not report the true max attainable..  and something discussed on here many times.   
As a very rough ball park figure, the real max attainable rate will be somewhere between the current sync speed and the max attainable rate shown by the modem.  ie  in your case ~ 68Mbps if the line did not have INP applied.



 
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

Uncleknobby

  • Just arrived
  • *
  • Posts: 1
Re: FTTC Weird DLM Situation
« Reply #9 on: May 23, 2019, 05:56:00 PM »

Would be nice to see your pair quality test results... if you get another engineer visit take a picture of both screens when the test is completed and post them here.
Logged
 

anything