G.INP / HG612

I have recently purchased an HG612 3B as my HH5 type A isn't G.INP compatible. The D side is quite noisy and has been for years, especially this time of year so was hoping a bit of vectoring would help.

I'm about 200m away from my Huawei 288 cab, used to get full sync but it has settled around the figures below for nearly 2 years now.

The HG612 is flashed with the 08 firmware and the stats are below. From what I can see G.INP hasn't kicked in yet?

xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 23597 Kbps, Downstream rate = 60936 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 61656 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): 14.4 0.0
Pwr(dBm): 13.9 5.3
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 243 237
M: 1 1
T: 0 42
R: 10 16
S: 0.1260 0.3781
L: 16125 5374
D: 8 1
I: 254 127
N: 254 254
Q: 8 0
V: 0 0
RxQueue: 48 0
TxQueue: 16 0
G.INP Framing: 18 0
G.INP lookback: 16 0
RRC bits: 0 24
Bearer 1
MSGc: 122 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 8.0000 0.0000
L: 32 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 322788
OHFErr: 0 1
RS: 40471832 666203
RSCorr: 4747 7
RSUnCorr: 0 0
Bearer 1
OHF: 79750 0
OHFErr: 0 0
RS: 637509 0
RSCorr: 0 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 57455 0
rtx_c: 16 0
rtx_uc: 0 0

G.INP Counters
LEFTRS: 0 0
minEFTR: 61662 0
errFreeBits: 1204149 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 151856697 0
Data Cells: 1573553 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: 0 1
SES: 0 0
UAS: 24 24
AS: 1281

Bearer 0
INP: 47.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 3.98
OR: 0.01 64.22
AgR: 61719.53 20063.54

Bearer 1
INP: 2.00 0.00
INPRein: 2.00 0.00
delay: 0 0
PER: 16.06 0.01
OR: 63.75 0.01
AgR: 63.75 0.01

Bitswap: 143/143 1/1

Total time = 21 min 45 sec
FEC: 4747 7
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 24 24
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 6 min 45 sec
FEC: 3405 7
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 1342 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 24 24
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 21 min 45 sec
FEC: 4747 7
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 24 24
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 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
Since Link time = 21 min 21 sec
FEC: 4747 7
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0

Yes it has.

But by the way, vectoring and G.INP are completely different things. Unless you mentioned it as a wish for the future you were confused.

G.INP is indicated by the mere presence of the Bearer 1 line and later details. It shows as zero sync because it is (we are told) always 200kbps, which rounded is 0kbps.

It is also a fair guess from the Bearer 0 interleaving depth (D 8 1) and the later Bearer 0 "delay: 0". On FTTC Fast Path is, as on ADSLx, 1 1, but with interleaving alone on the downstream depth is never below several hundred and often a few thousand. The "delay" line is also present on ADSLx as well as FTTC and shows the additional latency that has been applied at the same time as interleaving was activated. G.INP keeps the tiny bit of interleaving depth, typically 8, but sometimes 4 or 8, (I've had all three in the last few days), and removes the delay.

Hope that helps .

Does G.INP work alongside interleaving then?

I was hoping for a bit more of a speed increase than that, it's been 60/20 for a long time now.

Yes, but as you can see - only a tiny amount. What is does a lot is re-transmit duff packets rather than try to correct them. See the Retransmit counters.

Your speed loss is probably just down to increased crosstalk as more people on your cabinet took up FTTC. Without G.INP you would lose several Mbps more because of heavy interleaving.

In reply to a post by wolvesmad:

Does G.INP work alongside interleaving then?

Yes. G.INP uses a very low level of interleaving - depths of 8 or 16 are common, rather than the 1000+ seen in old-style FEC+interleaving.

That low level amounts to around 0.2ms of extra latency, rather than the 8ms+ used in old-style (and, as Robertos mentions, is specified in the "delay" parameter).

G.INP also uses a low-level of FEC overhead too - about 4% of the bandwidth, instead of 20% of the bandwidth.

In your case, the stats show that you encountered about 5,000 bit errors. Almost all of them were fixed by the (low amount of) FEC and interleaving, leaving 16 blocks that needed to be retransmitted. Those were retransmitted successfully ... so you ended up with 0 ES's - which gets counted as an error-free line.

As you can see, the settings for FEC and interleaving take away some of the load from the retransmission side of things.

In reply to a post by wolvesmad:

I was hoping for a bit more of a speed increase than that, it's been 60/20 for a long time now.

If your line had the old-style interleaving and FEC configured by DLM, then I would have expected something of a speed increase too. If it didn't, then some speed improvements are possible, but not guaranteed.

Thanks for breaking the stats down, makes sense a bit now.

What are those bit errors?

Pretty sure it was running interleaved, the ping was higher than 11ms to BBC which it is now.

I'll post some more stats up in a few days, see what's going on.

So what happens now then? Does G.INP keep it on that sync for as long as it's stable / the modem is manually forced to resync due to a power outage etc or will DLM try removing it at some point?

Once G.INP is on, so far as we can tell it stays on until the errors caused by something like a line fault completely overwhelms what it can sort out by retransmissions.

I seem to remember just a single case of that, where it was turned off and full interleaving turned back on. Note just one, out of hundreds we see here and no doubt thousands reading who would have posted if it had happened to them.

In reply to a post by wolvesmad:

What are those bit errors?

Corruptions in the 60Mbps bitstream, caused by electrical noise of some sort.

Cause? Perhaps some of the crosstalk from other subscribers; perhaps electrical noise induced from power lines; perhaps induced from lightning storms (though maybe not at this time of year), fluorescent lights, motors; perhaps ionospheric radiation picked up at twilight. Perhaps a dodgy joint, moving in the breeze, or soaked in a water-filled pit.

All the cables around here are underground but on ADSL the line used to be incredibly noisy and long, 52db attenuation. It was incredibly unstable on fastpath.

Due to the lack of VM around here, the crosstalk does seem to have an impact. I was the first person on the FTTC cab and had a rock solid 80/20 connection but over time it gradually started to fall and around 6 months in, settled around the 65/20 mark whilst the line stats pretty much stayed the same, attenuation etc.

42,000 FEC errors since Saturday midday. Is this on the high side?

In reply to a post by wolvesmad:

42,000 FEC errors since Saturday midday. Is this on the high side?

I've seen higher. But if they turn into very few retransmissions, and even fewer ESs, then the modems are coping just fine.