Thanks for the detailed reply, I’ve limited mine to 29Mb/15Mb and I can already see that DLM has not only dropped the interleaving it’s also increased the max sync by 4Mb~ so far and I am also on a Huawei cab.

The interesting thing is INPRein: 1.00 changed which suggests the re-transmits are high but looking at the ES rate sync the resync, it’s not showing anything errors on the DL just the UL


Since Link time = 15 hours 14 min 59 sec
FEC: 126 225
CRC: 0 26
ES: 0 21
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0

I can only assume DLM will take some time to sort it out, I did see that interleaving has dropped to 2 from 32 and I have noticed the latency us around 6ms, which is the same as I used to get on Zen.

This was the resync this morning

DLM resync

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 23228 Kbps, Downstream rate = 52608 Kbps
Bearer: 0, Upstream rate = 14997 Kbps, Downstream rate = 28999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 12.8 10.5
Attn(dB): 15.7 0.0
Pwr(dBm): 12.6 6.8

Bearer 0
INP: 57.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 7.62
OR: 0.01 36.70
AgR: 29190.49 15033.97


Before Resync

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Last initialization procedure status: 0
Max: Upstream rate = 21916 Kbps, Downstream rate = 48808 Kbps
Bearer: 0, Upstream rate = 14997 Kbps, Downstream rate = 28999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 13.1 9.7
Attn(dB): 15.7 0.0
Pwr(dBm): 12.7 6.7

Bearer 0
INP: 47.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 7.62
OR: 0.01 36.70
AgR: 29102.34 15033.97

Edited by RSR1 (Wed 01-Apr-20 18:22:36)

The higher the SNR the lower the attainable rate. Theoretically if your modem goes to 3dB SNR, then you'll get attainable rates that look very sexy and possibly over 100mbps - but don't worry about the attainable rate, it's just a calculation made from SNR values and not something we can possibly hope to achieve on our pair of rubbish lines!

DLM will take time to sort out. It works things out very slowly, but if after about 4-7 days nothing happens, call your ISP and ask for a 'DLM reset', and DLM will treat your line as if it's freshly connected. I'd advise doing that once you've got everything very stable though, as it will kick in with interleaving again otherwise.

INPRein is bad. 'REIN' is 'Repetitive Electromagnetic Impulse Noise', which means you have something that's impacting your line badly, and the INP (Impulse Noise Protection) is kicking in to try and mediate the problem. This most likely being caused by a power line.

This is something you can legitimately whinge to your ISP and call out an engineer for, but only if it's on the other side of the NTE. So first, make sure that the RJ11 cable from the modem to the NTE is as clear as possible from the power supply cable to the modem is as separated as possible. Those power warts can be stupidly noisy. When you're sure the modem's DSL line is clean, resync the modem.

If that REIN still exists, then call your ISP and mention to them you suspect REIN on the line. This will most likely result in an SFR investigation, and an Openreach engineer will go and inspect every part of the line to ensure that the noise is eliminated. But if he finds it's in your house, you'll have to pay for the call out, hence why I asked you to make sure first.

I've been making solid progress restoring on the speed on my line as I have gained 10Mb~ on where my line has started about 5 days ago.

Since the DLM reset this morning, its now showing the following from where it started. (You can pull stats by running - xdslcmd info --stats on a unlocked HG612)

Max: Upstream rate = 23435 Kbps, Downstream rate = 58904 Kbps

I've been limiting the line rate by running the following on my HG612 - xdslcmd configure --maxDataRate 29000 15000 100000

Bearer: 0, Upstream rate = 14997 Kbps, Downstream rate = 28999 Kbps

I will start to bring the speed from tomorrows re-sync if the DLM pattern holds true. However at the current speeds the line is free from any errors

Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0

What is interesting though, since i've limited the line I can see the following

Bearer 0
INP: 57.00 0.00
INPRein: 1.00 0.00

Bearer 0, INPRein 0 is Retx Low
Bearer 0, INPRein 1 is Retx High

I expect this to change shortly though as well.

but the interleaving depth is quiet low.

D: 2 1

As it used to run much higher, which in theory means mines the latency should be nice and low.

I will also be moving this line back to Zen from AA ISP.

Edited by RSR1 (Sun 05-Apr-20 15:12:54)

IIRC the latency addition is shown by the delay line.

Is Bearer 1 still present? That is there when G.INP is active. It shows 0Kbps, but is actually 200bps rounded down. Also I think delay is to be expected to be zero with G.INP.

Edited by RobertoS (Sun 05-Apr-20 16:43:00)

Yes. Bearer 1 is present.

As its shows the following settings:

Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01

Edited by RSR1 (Sun 05-Apr-20 17:46:16)

As RoberoS points out the Interleaving depth is completely irrelevant to latency.

You need to look at the Bearer 0 delay stats which is always 0 with G.INP.

There's only additional delay on Interleaving without G.INP, which is usually "delay: 8" which adds 8ms to latency.
High Interleaving can add 16ms delay/latency.

This should only be relevant for ECI cabinets as all lines on Huawei cabinets should have G.INP applied shortly after going live,switching ISP or having a DLM reset.
ECI cabinets have a G.INP trial running again but it's only been seen on a very small number of Plusnet lines who specifically opted in to the trial.

Retx Low/High doesn't effect latency.
It has an impact on throughput as Retx High has a lower IP profile so Retx Low would be preferable.

I recommend keeping the cap in place until Retx Low is applied.

That was my plan to see where it evens out, as above though I'm on a Huawei cabinet.

Here are the current stats off the line.

# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 22827 Kbps, Downstream rate = 58548 Kbps
Bearer: 0, Upstream rate = 14997 Kbps, Downstream rate = 28999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 12.6 10.0
Attn(dB): 15.7 0.0
Pwr(dBm): 12.6 6.7
VDSL2 framing
Bearer 0
MSGc: -6 29
B: 228 31
M: 1 1
T: 0 64
R: 16 2
S: 0.2501 0.0678
L: 7838 4009
D: 2 1
I: 245 34
N: 245 34
Q: 2 0
V: 1 0
RxQueue: 138 0
TxQueue: 23 0
G.INP Framing: 18 0
G.INP lookback: 23 0
RRC bits: 0 24
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 1256885
OHFErr: 0 16
RS: 954108608 4117973
RSCorr: 102 124
RSUnCorr: 0 0
Bearer 1
OHF: 3727999 0
OHFErr: 0 0
RS: 22367627 0
RSCorr: 0 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 115953 0
rtx_c: 1160 0
rtx_uc: 318323 0

G.INP Counters
LEFTRS: 98 0
minEFTR: 29001 0
errFreeBits: 1369581236 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 3339421803 0
Data Cells: 933681097 0
Drop Cells: 0
Bit Errors: 0 0

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

ES: 59 729
SES: 59 39
UAS: 320 261
AS: 59882

Bearer 0
INP: 57.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 7.62
OR: 0.01 36.70
AgR: 29190.49 15033.97

Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01

Bitswap: 12901/12901 24/24

Total time = 1 days 23 hours 41 min 10 sec
FEC: 97398 12063
CRC: 3254 2032
ES: 59 729
SES: 59 39
UAS: 320 261
LOS: 4 0
LOF: 56 0
LOM: 21 0
Latest 15 minutes time = 11 min 10 sec
FEC: 0 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: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 23 hours 41 min 10 sec
FEC: 182 1623
CRC: 559 101
ES: 10 41
SES: 10 7
UAS: 36 26
LOS: 1 0
LOF: 10 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 197 4728
CRC: 0 245
ES: 0 87
SES: 0 2
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 16 hours 38 min 1 sec
FEC: 102 124
CRC: 0 16
ES: 0 13
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#

Just to add, the cap on the upstream isn't needed.
DLM treats upstream/downstream independently.

Upstream Retx is only turned on when needed (high ES for example) and it isn't needed on your line.

In reply to a post by j0hn83:

Just to add, the cap on the upstream isn't needed.
DLM treats upstream/downstream independently.

Upstream Retx is only turned on when needed (high ES for example) and it isn't needed on your line.

Ahh excellent, I will change that tomorrow after ther resync.

This has been a interesting learning curve but all good.

In reply to a post by j0hn83:

Just to add, the cap on the upstream isn't needed.
DLM treats upstream/downstream independently.

Upstream Retx is only turned on when needed (high ES for example) and it isn't needed on your line.

I'm not on a G.INP line, but I'd have thought SNR margins still matter? Upstream and downstream SNR's in my experience, especially on a high-att line like his and mine, seem to need to be roughly equal to ensure the ES counts stay low and that mixed SNRs on upstream/downstream directly affect the other part of the line. Unless there's some magic that G.INP does with SNR that I don't know?