cancel
Showing results for 
Search instead for 
Did you mean: 

G.INP applied to upstream

jafreer
Aspiring Pro
Posts: 858
Thanks: 41
Registered: ‎13-10-2012

G.INP applied to upstream

I noticed today that my modem resynced in the early hours of yesterday morning and G.INP has been applied to the upstream.

 

I am pretty sure this is a new development as it has been a long time since I saw G.INP on the upstream (over a year I would say).

Has anyone noticed anything similar?

PS. I got a welcome upstream speed increase in the process.

15 REPLIES 15
30FTTC06
Pro
Posts: 2,286
Thanks: 108
Fixes: 4
Registered: ‎18-02-2013

Re: G.INP applied to upstream

Huawei........................ I gather ?

Oldjim
Resting Legend
Posts: 38,460
Thanks: 787
Fixes: 63
Registered: ‎15-06-2007

Re: G.INP applied to upstream

been like that for ages here

jafreer
Aspiring Pro
Posts: 858
Thanks: 41
Registered: ‎13-10-2012

Re: G.INP applied to upstream

Yes, Huawei cabinet

30FTTC06
Pro
Posts: 2,286
Thanks: 108
Fixes: 4
Registered: ‎18-02-2013

Re: G.INP applied to upstream

I've not seen G.INP upstream since the trial around here.

Stats recorded 13 Mar 2017 20:19:14

DSLAM/MSAN type:        	BDCM:0xa48c / v0xa48c
Modem/router firmware:  	AnnexA version - A2pv6C038m.d24j
DSL mode:               	VDSL2 Profile 17a
Status:                 	Showtime
Uptime:                 	14 days 10 hours 36 min 43 sec
Resyncs:                	0 (since 13 Mar 2017 20:18:12)
			
				Downstream	Upstream
Line attenuation (dB):  	24.4		0.0
Signal attenuation (dB):	Not monitored		
Connection speed (kbps):	40000		2000
SNR margin (dB):        	9.2		16.1
Power (dBm):            	11.2		0.9
Interleave depth:       	16		1
INP:                    	45.00		0
G.INP:                  	Enabled		Not enabled
Vectoring status:       	5 (VECT_UNCONFIGURED)		

RSCorr/RS (%):          	0.0089		0.0434
RSUnCorr/RS (%):        	0.0000		0.0000
ES/hour:                	0		0
Oldjim
Resting Legend
Posts: 38,460
Thanks: 787
Fixes: 63
Registered: ‎15-06-2007

Re: G.INP applied to upstream

you wouldn't as with your stats it isn't needed

mine started when I had a burst of upstream errors, then dropped off again, then another burst of errors and it came back along with banded upstream

DSLAM/MSAN type:        	BDCM:0xa48c / v0xa48c
Modem/router firmware:  	AnnexA version - A2pv6F039g1.d24m
DSL mode:               	VDSL2 Profile 17a
Status:                 	Showtime
Uptime:                 	12 days 17 hours 30 min 45 sec
Resyncs:                	1 (since 01 Mar 2017 16:19:57)
			
				Downstream	Upstream
Line attenuation (dB):  	21.2		0.0
Signal attenuation (dB):	Not monitored		
Connection speed (kbps):	41165		9997
SNR margin (dB):        	6.9		5.7
Power (dBm):            	12.6		7.1
Interleave depth:       	8		4
INP:                    	48.00		43.00
G.INP:                  	Enabled		Enabled
Vectoring status:       	5 (VECT_UNCONFIGURED)		

RSCorr/RS (%):          	0.3601		235.4096
RSUnCorr/RS (%):        	0.0000		0.0000
ES/hour:                	0		0
jafreer
Aspiring Pro
Posts: 858
Thanks: 41
Registered: ‎13-10-2012

Re: G.INP applied to upstream

@Oldjim - based on your comment I think I know what happened. I have been on fastpath for some time on the upstream and I am now showing an interleaving depth of 4. So I suspect what happened is that DLM intervened (due to some errors/noise etc) to increase the upstream interleaving depth from 1 to 4. I am assuming G.INP is not used on fastpath, so I never saw it. Now that it i'm not on fastpath anymore, G.INP is active.

So rather than this being a case of G.INP not being available, I think I just never saw it until I came off fastpath.

 

Just as an additional point. The upstream speed increase I got coming off fastpath almost makes it worthwhile not to be on fastpath. I am assuming there may be a very slight increase in ping as a result of moving to an interleaving depth of 4, but the 1.5 to 2Mbps speed gain more than makes up for it. Maybe I will need to ensure a little bit of noise on my line to retain this speed gain!

ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: G.INP applied to upstream

No, it's simply that the very small interleaving depth is what you get on Huawei cabinets when G.INP gets enabled. The DLM did not decide to increase the interleaving depth, it decided to enable retransmission (G.INP).

Interleaving depth on its own is not a particularly important value, it also depends on the interleaving block size. On Huawei cabinets, things are done so that the interleaving covers one DTU (smallest lump of data that can be re-transmitted).

jafreer
Aspiring Pro
Posts: 858
Thanks: 41
Registered: ‎13-10-2012

Re: G.INP applied to upstream

Thanks ejs - so this was actually G.INP being re-enabled rather than a DLM intervention because of noise?

Either way, it is a welcome change as it brings my upstream rate close to the product maximum (10 Mbps).

ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: G.INP applied to upstream

I thought G.INP being enabled is a DLM intervention because of errors / noise / retrains.

jafreer
Aspiring Pro
Posts: 858
Thanks: 41
Registered: ‎13-10-2012

Re: G.INP applied to upstream

Maybe I am confused. I thought you said the exact opposite in your previous post.

ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: G.INP applied to upstream

I'll try and re-phrase what I said before then.

The DLM decided to enable G.INP as a form of error protection, rather than using interleaving for error protection, or continuing with no error protection.

The implementation of G.INP on Huawei cabinets includes using a very small amount of interleaving, this detail of the implementation is not particularly important except to explain why that very small amount of interleaving has appeared.

jafreer
Aspiring Pro
Posts: 858
Thanks: 41
Registered: ‎13-10-2012

Re: G.INP applied to upstream

Thanks ejs. So I was almost right first time around. DLM did intervene because of noise/errors but it did it by switching on G.INP and the increase in interleaving was just a by product of that. I think I had said that DLM had intervened due to noise/errors and increased interleaving, and that G.INP was just a by product of that. I understand the difference though it seems kind of academic. It sounds like a change from fastpath would have resulted in interleaving being switched on, irrespective of whether it made the interleaving depth 4 or higher.

ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: G.INP applied to upstream

Yes, but ECI cabinets did G.INP slightly differently (with an interleaving depth of 1).

jafreer
Aspiring Pro
Posts: 858
Thanks: 41
Registered: ‎13-10-2012

Re: G.INP applied to upstream

Thanks for the info ejs - interesting stuff.