G.INP - How long to enable?

Hi all,

I've been on a Huawei cabinet with BT Inifinity 1 for a year (ECI modem) and just switched to Infinity 2 and swapped to an HG612 3B which I've unlocked. It's been up for 8 days now with no sign of G.INP. My stats are below.

A) is this a good line? and B) is it usual to wait this long for G.INP?

Stats recorded 09 Mar 2017 09:39:23

DSLAM/MSAN type: BDCM:0xa48c / v0xa48c
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 7 days 22 hours 57 min 31 sec
Resyncs: 0 (since 02 Mar 2017 14:14:50)

Downstream Upstream
Line attenuation (dB): 13.5 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 73362 19999
SNR margin (dB): 6.3 15.1
Power (dBm): 13.3 2.7
Interleave depth: 1 1
INP: 0 0
G.INP: Not enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)

RSCorr/RS (%): N/A 1.6588
RSUnCorr/RS (%): N/A 0.0000
ES/hour: 92.3 48.0


xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 27636 Kbps, Downstream rate = 73588 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 73362 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 15.1
Attn(dB): 13.5 0.0
Pwr(dBm): 13.3 2.7
VDSL2 framing
Bearer 0
MSGc: 18 26
B: 239 237
M: 1 1
T: 22 42
R: 0 16
S: 0.1041 0.3781
L: 18440 5374
D: 1 1
I: 240 127
N: 240 254
Counters
Bearer 0
OHF: 398581146 4122851
OHFErr: 777 397
RS: 0 479214
RSCorr: 0 7949
RSUnCorr: 0 0

Bearer 0
HEC: 1915 0
OCD: 140 0
LCD: 140 0
Total Cells: 2452530115 0
Data Cells: 2030535147 0
Drop Cells: 0
Bit Errors: 0 0

ES: 609 362
SES: 0 0
UAS: 25 25
AS: 687451

Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 1.72 3.98
OR: 111.32 64.22
AgR: 73472.99 20063.54

Bitswap: 231181/231181 427/427

Total time = 1 days 22 hours 57 min 56 sec
FEC: 0 7949
CRC: 777 397
ES: 609 362
SES: 0 0
UAS: 25 25
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 12 min 56 sec
FEC: 0 15
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 2
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 = 22 hours 57 min 56 sec
FEC: 0 630
CRC: 84 30
ES: 67 30
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 673
CRC: 89 44
ES: 74 42
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 7 days 22 hours 57 min 31 sec
FEC: 0 7949
CRC: 777 397
ES: 609 362
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#

It's only switched on if DLM thinks your line needs it.

As lee says, plus.

Yes, you have a good clean line. You are also on Fast Path in both directions, because of that. The "D: 1 1" tells us Fast Path. A number higher than 1 is the interleave depth, the number of packets a real one is split over. 1 obviously means packets are not being split .

G.INP is only used when you have heavy interleaving, as that gives you extra latency of at least 8ms, see the "Delay:" line which is zero addition on your line, and also costs up to 11Mbps.

G.INP drops the interleaving depth to a low level, usually 8, delay usually back to zero and sync back to pretty much the same as Fast Path.

You simply don't need it .

It is true that DLM will only activate it if it thinks you need it and your modem can support it.

However, I thought the default thinking for DLM was that every line needs G.INP unless there is conflicting evidence. The measurements showed that the installed base shifted from 10% of lines being error-free (ie zero ES in 24 hours) to 66%. Almost everyone benefits from it.

This is a line running at near 100 ES per day, and looks like it would benefit too.

To the OP:
Sometimes the activation happens in a couple of days, sometimes in a couple of weeks. However, DLM has been a little strange in the last year, not always doing the obvious things. And I'm expecting it to change behaviour again this spring, as BT rollout changes to both Huawei and ECI cabs.

The HG612 also needs to be running the most recent firmware.

In reply to a post by WWWombat:

However, I thought the default thinking for DLM was that every line needs G.INP unless there is conflicting evidence.

During the abortive G.Inp test on ECI cabinets, applying G.Inp to a stable fastpath line caused a 5 Mbps drop in sync.

G.INP was just enabled (downstream only). I re-PPPd to get a higher IP profile (now 75.6MBit as opposed to 71.2MBit) but download tests are showing speeds less than before (around 60MBit, whereas before it was consistently 69MBit).

Is it a case of waiting for things to settle?


DSLAM/MSAN type: BDCM:0xa48c / v0xa48c
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 4 hours 55 min 11 sec
Resyncs: 1 (since 02 Mar 2017 14:14:50)

Downstream Upstream
Line attenuation (dB): 13.5 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 78224 19999
SNR margin (dB): 6.3 15.1
Power (dBm): 13.3 3.0
Interleave depth: 8 1
INP: 49.00 0
G.INP: Enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)

RSCorr/RS (%): 0.0000 0.0026
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 37.8 17.9

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 27732 Kbps, Downstream rate = 77500 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 78224 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): 6.3 15.1
Attn(dB): 13.5 0.0
Pwr(dBm): 13.3 3.0
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 243 237
M: 1 1
T: 0 42
R: 10 16
S: 0.0993 0.3781
L: 20458 5374
D: 8 1
I: 254 127
N: 254 254
Q: 8 0
V: 0 0
RxQueue: 63 0
TxQueue: 21 0
G.INP Framing: 18 0
G.INP lookback: 21 0
RRC bits: 0 24
Bearer 1
MSGc: 186 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 5.3333 0.0000
L: 48 0
D: 3 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 235319
OHFErr: 0 13
RS: 710475952 2664845
RSCorr: 215 69
RSUnCorr: 0 0
Bearer 1
OHF: 1102692 0
OHFErr: 0 0
RS: 13231564 0
RSCorr: 0 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 37 0
rtx_c: 19 0
rtx_uc: 47936 0

G.INP Counters
LEFTRS: 10 0
minEFTR: 78212 0
errFreeBits: 22479529 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2664395277 0
Data Cells: 21087459 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: 681 399
SES: 21 0
UAS: 92 71
AS: 17713

Bearer 0
INP: 49.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 3.98
OR: 0.01 64.22
AgR: 78304.39 20063.54

Bearer 1
INP: 4.00 0.00
INPRein: 4.00 0.00
delay: 3 0
PER: 16.06 0.01
OR: 95.62 0.01
AgR: 95.62 0.01

Bitswap: 5829/5829 3/3

Total time = 1 days 2 min 57 sec
FEC: 3187 73
CRC: 560 13
ES: 681 399
SES: 21 0
UAS: 92 71
LOS: 2 0
LOF: 18 0
LOM: 0 0
Latest 15 minutes time = 2 min 57 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 1
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 = 2 min 57 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 1 day time = 24 hours 0 sec
FEC: 3187 73
CRC: 560 13
ES: 68 34
SES: 21 0
UAS: 67 46
LOS: 2 0
LOF: 18 0
LOM: 0 0
Since Link time = 4 hours 55 min 11 sec
FEC: 215 69
CRC: 0 13
ES: 0 13
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0

Drop the PPPOE session again on the router, if the throughput doesn't go up then it would appear BT are somehow capping your throughput, Have you tried several speed testers, that BTW isn't accurate in the grand scheme of things

Post deleted by j0hn83

Edited by j0hn83 (Fri 10-Mar-17 15:37:20)

In reply to a post by simon194:

In reply to a post by WWWombat:

However, I thought the default thinking for DLM was that every line needs G.INP unless there is conflicting evidence.

During the abortive G.Inp test on ECI cabinets, applying G.Inp to a stable fastpath line caused a 5 Mbps drop in sync.

The "abortive G.INP tests on ECI cabinets" may not have been the best example to choose. They were, after all, aborted for a reason.

On my line (Huawei cab, with either HG612 modem or Billion 8800NL router/modem), activation of G.INP caused the max-attainable to jump by 8Mbps, from 100 to 108Mbps.

Edited by deleted (Sat 11-Mar-17 12:35:21)