Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: GigabitEthernet on April 27, 2021, 02:12:26 PM
-
Been on FTTC at this address since the 13th March. Except for when I was put on the wrong product and then moved to the correct one, DLM has never intervened.
The connection has variably been up for two+ weeks at a time, only dropping when I rebooted the router.
Target SNRM is still at 6dB, it's a TalkTalk router so I can't see the errors but is DLM just never going to act?
-
but is DLM just never going to act?
That's very likely.
The DLM only lowers the target SNRM on some lines. Many lines stay on 6dB forever.
The DLM profile used by the ISP plays a part and Talktalk (if you use them) use the Standard DLM profile and not the preferred Speed DLM profile.
It's been observed in other threads that manually capping the downstream sync rate can nudge the DLM in to lowering the target.
For some lines it will just never change.
We have no idea what the DLM is looking for.
-
Are you with talktalk?
I have moved ISP from plusnet to talktalk, as I wanted to ditch PPPoE and connect via DHCP/IPoE.
Talktalk also have 1500 MTU without have to fiddle: https://community.talktalk.co.uk/t5/Articles/Set-up-a-non-TalkTalk-router/ta-p/2205383
Talktalk doesn't seem to use DLM or the xdB profiles either.
When with plusnet I was on a 3dB profile and low retx (INP 48).
With talktalk I have a fixed 6dB profile with low retx (INP 49).
-
>> Talktalk doesn't seem to use DLM or the xdB profiles either.
afaik 'x'db is now standard on all Huawei cabs. What I think will be making the difference is that TT uses the standard profile as already mentioned by j0hn.
When I was compiling all the info about DLM, there was hardly any available information (practically zilch!) from Openreach about changes that would increase the line speed. What I mean by that, is that Openreach provided information about how DLM is used to stabilise a line and it was 'sold' to the ISP's as being a beneficial thing - ie "Look what happens to stop your customers ringing up and complaining about their connection dropping out". So although we know what supposedly causes DLM to take action to stabilise the line, the info that was lacking is what causes the DLM to reverse any caps or interleave and increase the line speed. All I know is that it should be based around the error rate and the uptime.
Because 'x'db falls under the same umbrella as a positive DLM change , then we don't know what DLM considers an acceptable amount of errors and for how long, before it will reduce/reverse changes to the DLM. However because TT uses the standard profile, that means the levl of stability has to be maintained for a longer period with fewer error than those customers who are with an ISP using the speed profile.
-
I've seen plenty Talktalk lines with 3dB SNRM targets.
As kitz says it's standard on all Huawei lines.
Talktalk can't opt out of anything DLM related, no OpenReach GEA-FTTC ISP can.
They only get to choose the DLM profile which is usually the Speed or Standard profile.
A nice heavy Downstream cap for a few days/a week often nudges the DLM down to 5dB.
Once it has taken the 1st step to 5dB it usually continues down to 3dB on its own.
-
Thanks for the info. My FEC's are very low with this 6dB profile on my Huawei cab:
Previous 1 day time = 24 hours 0 sec
FEC: 22274 55
CRC: 0 307
ES: 0 205
For fun I will set a cap of 60,000 downstream (currently syncing at 70,539 - with 3dB the line could 'attain' 83,000+) - and report back :)
-
Now done:
DSLAM type / SW version: BDCM:0xa4a1 (164.161) / v0xa4a1
Modem/router firmware: AnnexA version - A2pv6F039v.d26a
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 0 hour 0 min 14 sec
Resyncs: 0 (since 28 Apr 2021 21:27:00)
Downstream Upstream
Line attenuation (dB): 16.7 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 60000 19000
SNR margin (dB): 9.4 16.1
Power (dBm): 13.4 7.1
Interleave depth: 16 1
INP: 48.00 0
G.INP: Enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
-
DLM has started the xdB stepping. Overnight DLM put me on 5dB:
DSLAM type / SW version: BDCM:0xa4a1 (164.161) / v0xa4a1
Modem/router firmware: AnnexA version - A2pv6F039v.d26a
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 8 hours 59 min 14 sec
Resyncs: 0 (since 30 Apr 2021 09:36:02)
Downstream Upstream
Line attenuation (dB): 16.7 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 73865 19999
SNR margin (dB): 5.3 15.4
Power (dBm): 13.3 7.2
Interleave depth: 8 1
INP: 52.00 0
G.INP: Enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
-
Good to see that the modem DS speed clamp has had the desired effect, hope the DS target SNRM continues to 3dB over time increasing DS synch speed.
Would guess that your line DS G.Inp re-tx profile has now changed from low to high, you can of course positively check this by looking at bearer 0 DS INPRein state (0=low, 1=high)
Have found on my line that G.Inp re-tx profile change from low to high can be a common bi-product of DS SNRM step changes instigated by modem DS speed clamping, also found once 3dB DS SNRM has been achieved retaining the DS clamp should eventually result in DS G.Inp re-tx low profile being re-applied provided the line can support this at the lower SNRM level.
-
Yep, 4dB:
DSLAM type / SW version: BDCM:0xa4a1 (164.161) / v0xa4a1
Modem/router firmware: AnnexA version - A2pv6F039v.d26a
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 10 hours 18 min 58 sec
Resyncs: 0 (since 02 May 2021 09:31:39)
Downstream Upstream
Line attenuation (dB): 16.7 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 77188 19999
SNR margin (dB): 4.3 15.3
Power (dBm): 13.4 7.1
Interleave depth: 8 1
INP: 52.00 0
G.INP: Enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
-
A nice heavy Downstream cap for a few days/a week often nudges the DLM down to 5dB.
Once it has taken the 1st step to 5dB it usually continues down to 3dB on its own.
;)
You should hit the full 80Mb in a couple days at 3dB.
-
Will DLM just put you back up to 6dB later on based on whatever later error rate there is?
-
Very unlikely, it seems to require higher numbers to pass a threshold to initiate an action.
Underzone, once it hopefully settles at 3dB, chances are you'll still be on ReTx High and it'll stick there, in which case capping it again will probably disable that and switch it back to ReTx Low.
-
Underzone, once it hopefully settles at 3dB, chances are you'll still be on ReTx High and it'll stick there, in which case capping it again will probably disable that and switch it back to ReTx Low.
Yes,that's usually the case but can take quite a long time for DLM action, on my line after a long period of DS G.Inp re-tx high state it initially took 14 days before DLM applied DS re-tx low profile.
From experience have found that quite a severe DS speed clamp producing a DS FEC error rate of approx 10,000 or less errors/hr (avg daily rate) as monitored by DSLStats was required, the time scale for DLM intervention appeared to be proportional to the length of time DS re-tx high state previously existed and the historic DS FEC error rate.
I'am well aware that no one knows exactly what parameters DLM monitors with respect to G.Inp re-tx profile selection, however, have found that DS FEC error rate is a reasonable guide to any DLM potential action on re-tx profile adjustment.
Have also found that once DS G.Inp re-tx low profile has been achieved, DLM is much more tolerant of DS FEC error rate, my line periodically reaches 20,000 errors/hr (avg daily rate) and has still maintained DS re-tx low profile.
-
Thanks for the info. My FEC's are very low with this 6dB profile on my Huawei cab:
Previous 1 day time = 24 hours 0 sec
FEC: 22274 55
CRC: 0 307
ES: 0 205
For fun I will set a cap of 60,000 downstream (currently syncing at 70,539 - with 3dB the line could 'attain' 83,000+) - and report back :)
That very clever bit cap 60000Kbps and DLM will act target 3dB SNR
-
Thanks adslmax, I found the info on this forum of course ;D. The command I used:
adsl configure --maxDataRate 60004 19004 100000
-
Last one:
DSLAM type / SW version: BDCM:0xa4a1 (164.161) / v0xa4a1
Modem/router firmware: AnnexA version - A2pv6F039v.d26a
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 5 hours 33 min 23 sec
Resyncs: 0 (since 04 May 2021 08:32:27)
Downstream Upstream
Line attenuation (dB): 16.7 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 79998 19999
SNR margin (dB): 3.3 15.5
Power (dBm): 13.4 7.1
Interleave depth: 8 1
INP: 51.00 0
G.INP: Enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
and:
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 27549 Kbps, Downstream rate = 81344 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79998 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
-
I'am well aware that no one knows exactly what parameters DLM monitors with respect to G.Inp re-tx profile selection,
The G.INP 'equivalent' of Err Secs is LEFTRs
SEFTR = Severe Loss of error-free throughput
LEFTR = Loss of Error Free Throughput - Count of seconds with a defect
As regards to what causes the DLM to relent its all rather vague especially once the line is banded. All the documentation I saw indicated that it depends on your ILQ status (https://kitz.co.uk/adsl/DLM.htm#DLM_categorising_the_line) being green for a period of time. Observations with lines that had been Interleaved bore this out, bearing in mind that there is also some sort of doubler system in place meaning each subsequent incident requires a longer period of ILQ green. BTw documentation repeatedly indicates the parameters of interest are ErrSecs and SES and one doc specifically ruled out FEC count. BS can confirm this as there was an equivalent Openreach doc. For clarity, absolutely none of the documentation or info came from him and were obtained from other sources long before. He was just trying to see if anything had been updated.
However, since the ASSIA court case which specifically seemed to target the Openreach DLM some changes were made that seems to make it exceedingly hard to reverse line caps. Those few that have done so naturally have taken an exceedingly long period of stability. My own line now must have been capped for over a year. I do still see that daily dose of SHINE which lasts for <1sec and the rest of the time it is perfectly fine and should have been ILQ green for extremely long periods of time.
I've pondered if the SNRM may be of interest - as there is some sort of linear relationship between the [Target] SNRM and amount of cap in place. eg incr SNRM by 1.5dB, 3dB etc. When we artificially limit the line speed it results in an artificially high SNRM.
I started off with the intention of deliberately not artificially restricting my line as an experiment to see if the DLM did relent on its own. It didn't despite having had what must be months of ILQ green... then I just got too lazy and too ill to care. Despite being capped at 60Mbps the line still does most of what I use it for now. My upstream is still at 20Mbps, but due to my circumstance I don't do any large amounts of uploading these days, so even what was a much used benefit when I first got FTTC, doesnt get the workout like it used to.
-
Last one:
DSLAM type / SW version: BDCM:0xa4a1 (164.161) / v0xa4a1
Modem/router firmware: AnnexA version - A2pv6F039v.d26a
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 5 hours 33 min 23 sec
Resyncs: 0 (since 04 May 2021 08:32:27)
Downstream Upstream
Line attenuation (dB): 16.7 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 79998 19999
SNR margin (dB): 3.3 15.5
Power (dBm): 13.4 7.1
Interleave depth: 8 1
INP: 51.00 0
G.INP: Enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
and:
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 27549 Kbps, Downstream rate = 81344 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79998 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
nice one! ;D
-
Thanks adslmax, I found the info on this forum of course ;D. The command I used:
adsl configure --maxDataRate 60004 19004 100000
Thanks I keep that for future if my line sync drop and stuck at 6dB for too long.
Mine still on sync rate 79999/19999 with max rate 82258/23466 with SNR at 6.5dB/7.4dB