G.INP off on Huawei cabs now??

It's now been 2 weeks since my migration from Plusnet to BT and G.INP still hasn't been re-enabled despite huge errors on the line - over 500,000 FEC/sec at some times of day.

Has G.INP been turned off on Huawei cabs now too? I hope not as my attainable is 69Mbps but I'm only sync'd at 58Mbps. When it was enabled before, I re-sync'd at 68Mbps ish.

I have G.INP just like many others.

Hmm is it normal then for mine still to have not been turned back on after 2 weeks? I haven't rebooted router for about 10 days - will rebooting help?

I remember when G.INP was enabled last summer, it was only after the power to the house had been off whilst I did some electrical work. When I turned it back on, it was enabled.

Looks like they have stopped tuning G.INP back on if it's been disabled by a DLM reset. This may be until they fix G.INP on ECI cabs.

AIUI at very high error levels G.INP simply isn't effective, as it only reserves a tiny amount of bandwidth to do the retransmission so can't cope at such levels. So DLM just turns it off and relies on good ol' interleaving.

I'd say 500,000 FECs per second is way too high and you have some sort of fault condition. However, I would have rebooted long ago.

Edited by RobertoS (Mon 09-May-16 09:11:08)

What's wrong with it on ECI cabs? It's enabled on mine and working perfectly.

The problem is it's not working perfectly for everyone, so it's being removed on some lines.

I had a BT engineer out last Tuesday (even though I'd cancelled him the day before!) but he couldn't find any fault on the line - he did say it should be faster though as he said the line is just over 200m long!

I wonder why G.INP was on before then? The only difference here is that I changed from Plusnet to BT. This has cost me nearly 10Mbps.

In reply to a post by Icaras:

What's wrong with it on ECI cabs? It's enabled on mine and working perfectly.

Downstream only, so not perfectly.

Well you said your 500,000 FECs/sec is intermittent. If it wasn't happening when he was there he wouldn't hang around waiting for it, would he. Therefore no fault found.

That's 500 per millisecond. Quite apart from any other error types. Keeping your modem busy, and quite hot I expect.

I didn't say it was intermittent - I said it was at certain times of the day. It is actually like clockwork and between the hrs of 19:00 and 22:30 the errors drop altogether. Obviously something on a timer causing it but I've checked everything on my property so unfortunately, it's elsewhere and therefore nothing that I can do anything about.

In reply to a post by BatBoy:

I have G.INP just like many others.

Apologies if this has been answered before. I have done a search and not come up with an answer.
How do I know if I have G.INP enabled on my HH5 A
Thanks.

You don't....

With the HH5 A and B you would need to ask BT to do a GEA Test and ask what the lines profile is...


However tiny chance BT will understand this let alone actually carry it out.

The way I've checked is to use a HG612 modem and readhy the stats, then compare the HH5's stats... however this is unreliable unless you know what yuou lines speeds are with or without error correction.

Post deleted by RobertoS

Ey? Shirty? How have you managed to take anything in my post above as 'getting shirty'?

Probably because I'm tired and frazzled to start with.

Sorry.

No probs. This day had taken it's toll on me too. Early night for me. If I can ever get my little girls to bed that is

I'm on an ECI cabinet and G.INP caused a 3 Mbps drop in sync. I'm not sure why it was ever applied because my line was stable on fastpath. Now I'm stuck with interleaving and an even lower sync and no sign of it switching back to fastpath.

I've noticed someone from another forum who's line was reset during an engineer visit and they are still stuck on Interleavin too.....

I've also been expecting G.INP to to be re-enabled on my upstream due to errors but thats not happened either, actually nothings changed and normally the G.INP's values and figures change upon resyncs based on errors picked up from local noise and crosstalk....

Just another Spring balls up by Openreach I suppose..... I do look forward to the future when someone snaps and pushes them out of control.....

In reply to a post by woodroyd:

In reply to a post by BatBoy:

I have G.INP just like many others.

Apologies if this has been answered before. I have done a search and not come up with an answer.
How do I know if I have G.INP enabled on my HH5 A
Thanks.

If you're connected to a Huawei cabinet you can use the following G.INP Formula to determine if your line has G.INP enabled as follows:

Divide your IP Profile by your Sync Speed and if the answer is 0.9669 you have G.INP or 0.9679 if you don't.

a full rollback, if you still have it on, then its only a matter of time before you lose it.

In reply to a post by BatBoy:

In reply to a post by woodroyd:

In reply to a post by BatBoy:

I have G.INP just like many others.

Apologies if this has been answered before. I have done a search and not come up with an answer.
How do I know if I have G.INP enabled on my HH5 A
Thanks.

If you're connected to a Huawei cabinet you can use the following G.INP Formula to determine if your line has G.INP enabled as follows:

Divide your IP Profile by your Sync Speed and if the answer is 0.9669 you have G.INP or 0.9679 if you don't.

and once again that is not a proven way to check at all.... different chipsets give different results.... please stop with this...

Works for me
YMMV

shame it don't for anyone else....

Works for me.

For a HG612 with Huawei DSLAM set up yes....

However it don't when non Broadcom DSL chips are in play.

Work for my HH5A and HH5B as well

From that logic then thats the argument settled, the HH5A support G.INP down, just like the HH5B...

or it means your line isn't G.INP enabled when any HH5 is connected.

In reply to a post by mlmclaren:

From that logic then thats the argument settled, the HH5A support G.INP down, just like the HH5B...

Nope. The results I published show the HH5A doesn't support G.INP and the HH5B does.
http://forums.thinkbroadband.com/bt/t/4476138-myths-...

See now I've just looked at that again and something has caught my attention....

With G.INP enabled on Broadcom based kit the actual sync is normally more than the attainable...

For example: SYNC:69319 ATTAIN:68284 (Taken from HG612)

Now I also saw this on the HH5A

For example:
6. Data rate: 19033 / 69194
7. Maximum data rate: 19033 / 69176

However oth of your samples as below:

HH5B:
6. Data Rate: 19999 / 76148
7. Maximum Data Rate: 24287 / 76746

HH5A:
6. Data rate: 19999 / 70778
7. Maximum data rate: 23506 / 72032

To me they both look like traditional fast path results.... I would say the '5A' looks Interleaved due to the 2000kbps unused in the attainable but this could be a bug or compatability issue with DSLAM.

PS. I'm not quiet sure how much you can trust the IP Profile system to be accurate either, I've found it to stick in the past, it has stuck taking 6Mb away from downstream throughput before now.

That's often the case in high noise environments like yours, the sync speed is fixed but the noise and max data rate vary continuously.

In reply to a post by BatBoy:

That's often the case in high noise environments like yours

Nope I don't believe so, this was the same on my previous line which performed just fine.... and is also similar story on many other G.INP lines (excluding ECI DSLAM's)

What I think BatBoy is saying is that at any given sync the noise margin varies just like it does on ADSLx. As your noise margin rises, your max available rises, and vice versa.

Bitswapping whilst connected also causes the attainable to fall as bits declared unusable in a bin are no longer available and some of the available in other bins are used to maintain the sync.

Attainable being below actual is seen very often on these forums except when (non-G.INP) interleaving is active.

Edited by RobertoS (Tue 10-May-16 20:36:24)

Yes I know that.....

I'm not arguing about it anymore, it is capable, I've watched it become capable last year when G.INP first surfaced and I've tested it again....

Others seem to agree it is capable... the industry has siad it is capable, therefore it is capable...

If one person is that hell bent on saying it isn't capable then they better provide better proof that it isn't...

END.

Note, the sentence before the one of BatBoy's that you challenged. It is ECI cabinets where the two ratios are questionable, not the modems on a Huawei cabinet.

The G.INP Formula does not work for me it's well of by 0.5 percent it's showing as 91.2 percent

What modem and cabinet makes please?

Edited by RobertoS (Wed 11-May-16 23:27:54)

HG612 plus Huawei cabinet

I'd like to see the full stats from the HG612 if possible please, and also the downstream text box of the BT Wholesale Performance Test Further Diagnostics page.

Download speedachieved during the test was - 30.6 Mbps
For your connection, the acceptable range of speedsis 20 Mbps-30.74 Mbps .
Additional Information:
IP Profile for your line is - 30.74 Mbps

HG612 stats

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 6274 Kbps, Downstream rate = 33508 Kbps
Bearer: 0, Upstream rate = 6274 Kbps, Downstream rate = 33489 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.4 6.1
Attn(dB): 24.6 0.0
Pwr(dBm): 11.2 0.1
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 227 191
M: 1 1
T: 0 40
R: 10 12
S: 0.2165 0.9714
L: 8793 1680
D: 4 1
I: 238 102
N: 238 204
Q: 4 0
V: 0 0
RxQueue: 80 0
TxQueue: 20 0
G.INP Framing: 18 0
G.INP lookback: 20 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 93740
OHFErr: 396 1273
RS: 2393047696 2724340
RSCorr: 4037951 1959
RSUnCorr: 0 0
Bearer 1
OHF: 124348451 0
OHFErr: 1 0
RS: 746090335 0
RSCorr: 28367 0
RSUnCorr: 1 0

Retransmit Counters
rtx_tx: 656892 0
rtx_c: 404778 0
rtx_uc: 8959 0

G.INP Counters
LEFTRS: 284 0
minEFTR: 33492 0
errFreeBits: 1019327288 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 4073166937 0
Data Cells: 464521347 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: 133 1049
SES: 3 0
UAS: 18 18
AS: 1997400

Bearer 0
INP: 51.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 9.75
OR: 0.01 26.25
AgR: 33563.07 6300.09

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

That's interesting. I assume both are freshly taken. For the throughput to be so close to the IP Profile is remarkable. Which ISP are you with?

I'm wondering if there is any possibility you have had a very quick resync at some stage, and the IP Profile failed to rise.

have been able to resync the modem numerous times using 30min in the off position and the it always shows 91 to 92 % depending on what sync rate it gets at that time.

The issue is that the router is responsible for updating the IP Profile not the modem.

have switched the modem off/on many times and still same result

Not the modem, the router.

so sorry i meant to say the router not modem

It might not be something you can fix by rebooting the router, it could be just how you router works. Anyway, it's a rule of thumb and your mileage may vary. In your case, you can see if G.INP is on or off on your connection, other people can't.

Are you still on Infinity 40/10, and what version of firmware and software is on your HG612?

Software version V100R001C01B030SP08
Firmware version A2pv6C038m.d24j

think i am using the latest firmware and software here is the print out from the HG612

Software version = V100R001C01B030SP08
Software last change detected at 01/11/2014 at 12:35

Firmware version = A2pv6C038m.d24j
Firmware last change detected at 01/11/2014 at 12:34

CPU version = BCM6368
CPU last change detected at 01/11/2014 at 12:35

That's fine.

thanks for taking your time to have look into this for me