G.INP Off

My modem (7490) re-synced 3 times yesterday. G.INP is now off and interleaving applied. Sync. has dropped from its usual 79997/20000.

My Broadband Ping

Negotiated Connection Properties
Receive direction Send direction
Max. DSLAM throughput kbit/s 80000 20000
Min. DSLAM throughput kbit/s 128 128
Attainable throughput kbit/s 82255 22644
Current throughput kbit/s 70914 20000
Seamless rate adaptation off off

Latency 8 ms 0 ms
Impulse noise protection 3 0
G.INP off off

Signal-to-noise ratio dB 6 7
Bitswap on on
Line attenuation dB 11 10

Profile 17a
G.Vector off off

Carrier record A43 A43

Edited by bet_here (Thu 05-May-16 20:06:33)

Hi,

I also have a Fritz!Box 7490. It has been re-syncing a number of time over the past month since G.INP was turned on. First time it was on I had a sync of 79999 and over the past week or so the sync rate has been dropping. Yesterday however it re-synced and like you G.INP is off.

Receive direction Send direction
Max. DSLAM throughput kbit/s 74000 20000
Min. DSLAM throughput kbit/s 128 128
Attainable throughput kbit/s 77985 28407
Current throughput kbit/s 66029 20000
Seamless rate adaptation off off

Latency 8 ms 0 ms
Impulse noise protection 3 0
G.INP off off

Signal-to-noise ratio dB 6 10
Bitswap on on
Line attenuation dB 15 14

Profile 17a
G.Vector off off

Carrier record A43 A43

Have you given any feedback to AVM - I think this can be done via the web ui under the feedback tab in the DSL information section. Also are you set to Annex A or Annex B. I am set to Annex A but I don't want to change it as I'm not at home for a few days and don't want to do anything that may cause long term disconnection.

Cheers,
Al

In both cases, the likelihood is that your line is going through "growing pains" caused by BT.

They have been trying to roll out G.INP support (downstream only) to subscribers connected to ECI cabinets. For most lines, G.INP started running successfully, but there have been strange anomolies happening on some of the lines.

BT decided to remove the G.INP settings for all ECI cabinets, so your experience is likely to be a part of these.

However, the process of removing G.INP from a line means that the DLM profile is set back to a default setting - which is one where old-style INP intervention is in place; old-style intervention often means a 10% reduction in speed and an 8ms increase in latency.

Once back on this default profile for 2-3 days, DLM is likely (but not certain) to decide that old-style INP intervention is not necessary, and restore both speed and latency.

All it needs, for now, is patience.

Thanks WWWombat. I searched the forums and found out that they have turned off G.INP on ECI cabs as you rightly say.

https://community.bt.com/t5/BT-Infinity-Speed-Connec...

At least now I know what it is. I take it that Infineon 11.8.4 is an ECI cabinet.

Cheers,
Al

Edited by deleted (Fri 06-May-16 11:45:52)

Interested to read this - i have a Draytek 2860 which for the last couple of weeks showed G.inp enabled on the upstream only,DLM seems to be very confused & changes settings on a daily basis. G.INP was removed overnight. ECI cab on 780m of Aluminium.

Stats from yesterday

ATU-R Information
Type: VDSL2
Hardware: Annex A
Firmware: 05-07-06-0D-01-07
Power Mngt Mode: DSL_G997_PMS_L0
Line State: SHOWTIME
Running Mode: 17A
Vendor ID: b5004946 544e0000
ATU-C Information
Vendor ID: b5004946 544eb204 [IFTN]
Line Statistics

Downstream Upstream
Actual Rate 32678 Kbps 6307 Kbps
Attainable Rate 33088 Kbps 6376 Kbps
Path Mode Fast Fast
Interleave Depth 1 1
Actual PSD 4. 7 dB 11. 1 dB
Near End Far End
Trellis ON ON
Bitswap OFF ON
ReTx 0 1
SNR Margin 6 dB 6 dB
Attenuation 25 dB 37 dB

Stats today

Line Statistics

Downstream Upstream
Actual Rate 25665 Kbps 6148 Kbps
Attainable Rate 32210 Kbps 6150 Kbps
Path Mode Interleave Fast
Interleave Depth 1075 1
Actual PSD 4. 7 dB 11. 0 dB
Near End Far End
Trellis ON ON
Bitswap ON ON
ReTx 0 0
SNR Margin 6 dB 6 dB
Attenuation 25 dB 37 dB

Should this settle down now ?

Phil

Perhaps DLM does not cater for upstream G.INP allied to the heavy downstream interleaving it has introduced between the two sets of stats.

The Kitz forum is doing a better job of figuring out G.INP on ECI than I am alone, so any follow-ups may be best there.

Hopefully, the removal of G.INP should allow you to settle, with perhaps one more resync to take away the interleaving in a couple of days.

However, one thing that seems to have been very certain: ECI cabinets shouldn't be able to support G.INP upstream. Ever. I wonder if the Draytek was reporting correctly.

G.INP has been turned off on my connection for just over four days now, initially with an interleave of 927, this corrected itself to an interleave of 1 (fastpath) within 48 hours. In my case, i'm glad to see the back of it, we now have our previous downstream rate back with a much lower reported and perceived error level and (so far) no random slow-downs that we experienced with G.INP active.

I wish my connection would switch back to it's pre-G.INP fastpath state, but I guess it's only been nine days since G.INP was removed.

Will Openreach removed G.INP for all huawei cabinets after eci cabinets have completed?

Why would they do that? I didn't know there was any problem with Huwaei cabinets.

I prefer G.INP off with fast path as i always believe fast path is the best one for gaming overall.

AIUI G.INP is only applied instead of Interleaving. If a line is fit for Fast Path then neither is turned on.

G.INP with fastpath was applied to ECI cabs, but is now being removed.

We need to be careful about our definition and detection method of Fast Path here. On Huawei cabs we basically talk of G.INP removing interleaving, but it doesn't. Fast path is however possible without G.INP.

Given the stats invisibility on ECI and some other modems definitive statements are risky.

What is certain is that G.INP on ECI cabs is in chaos, as it is with ECI and possibly some other modems.

I'm referring to an interleave depth of 1 being the equivalent (or approximation) of fastpath.

Mine is G.INP enabled with huawei cabinet with interleave depth of 16 (downstream) and 1 (upstream) mean it still interleaved ON! I think the higher interleave depth of 16 was pretty bad, should be 8 instead.

My FTTC Stats as interleaved ON below:

Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 12.7 15.4
Attenuation (dB) 11.1 0.0
Output Power (dBm) 12.5 -0.9
Attainable Rate (Kbps) 106140 34829
Rate (Kbps) 79999 19999
B (# of bytes in Mux Data Frame) 130 237
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 42
R (# of redundancy bytes in the RS codeword) 8 16
S (# of data symbols over which the RS code word spans) 0.0518 0.3781
L (# of bits transmitted in each data symbol) 21468 5374
D (interleaver depth) 16 1
I (interleaver block size in bytes) 139 127
N (RS codeword size) 139 254
Delay (msec) 0 0
INP (DMT symbol) 48.00 0.00
OH Frames 0 0
OH Frame Errors 2565 21132
RS Words 3454159760 2136930
RS Correctable Errors 45155 9511
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 2613053748 0
Data Cells 2229227546 0
Bit Errors 0 0
Total ES 223 11206
Total SES 36 0
Total UAS 571 546
System Up-Time 166D 18H 26M 34S
Connection Time 166 Day(s) 18:27:33

Edited by adslmax (Sun 08-May-16 12:50:26)

However, the gaming-important latency addition customary with non G.INP interleaving, which I assume is what bothers you about interleaving, is zero. The "Delay" line in the stats.

Thanks didn't know that interleaved is OFF because Delay set 0/0, never thought of that.

Interleaving is on, but is not affecting the latency. Interleaving has always added to latency by the "Delay" amount on BT Wholesale DLM, and on Openreach DLM when G.INP is not active.

I lost G.INP over this weekend and my speed went down from 78 to 67.

That's normal if full interleaving has replaced it. I assume your latency has gone up by at least 8ms?