When G.INP kicks in the speed normally increases a lot, but not as high as the existing "Attainable", which will fall. A slight residual interleaving may remain but without the usual increased latency. See mine below. Bearer 1 is what G.INP introduces, D: line is the interleaving depth, delay: line is the addition to latency from Fast Path.

# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 14015 Kbps, Downstream rate = 58076 Kbps
Bearer: 0, Upstream rate = 14372 Kbps, Downstream rate = 59999 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): 5.3 6.1
Attn(dB): 19.8 0.0
Pwr(dBm): 13.5 7.4
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 174 237
M: 1 1
T: 0 62
R: 8 16
S: 0.0928 0.5267
L: 15775 3858
D: 16 1
I: 183 127
N: 183 254
Q: 16 0
V: 3 0
RxQueue: 33 0
TxQueue: 11 0
G.INP Framing: 18 0
G.INP lookback: 11 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 844233
OHFErr: 88 43
RS: 1203312224 3158407
RSCorr: 1997394 588
RSUnCorr: 0 0
Bearer 1
OHF: 45341260 0
OHFErr: 0 0
RS: 362729587 0
RSCorr: 24 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 8945 0
rtx_c: 78592 0
rtx_uc: 40994 0

G.INP Counters
LEFTRS: 1194 0
minEFTR: 59987 0
errFreeBits: 92407352 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2428138872 0
Data Cells: 121146367 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: 59 159
SES: 13 0
UAS: 300 289
AS: 728311

Bearer 0
INP: 47.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 8.19
OR: 0.01 31.23
AgR: 60106.73 14403.64

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: 509468/509469 10137/10166

#

Edited by RobertoS (Fri 18-Sep-15 10:57:14)

Fi g.inp then interleaving (at least to any great depth) isn't an issue, but I thought you were implying you were on a cabinet where interleaving wasn't currently implemented as I believe some of the older ones have problems in that area.

In any event, my advice would be to leave well alone for a few days and let it settle down. I would not try and force change through manually induced resyncs.

The whole batch of recent posts on here needs a more carefully considered response from me, but I have to go out...

In reply to a post by CaptainJack:

Welp, another set of engineers arrived and did some work remotely, which, happily, has now resolved the noise with the voice line (moved me to a different set of wires between two junction points?).

However, this did little to improve my internet speeds. My latest xDSL stats:

https://dl.dropboxusercontent.com/u/43025045/Screens...

If I read that rightly, your downstream attenuation has gone up by about 5dB. This latest report says over 22dB, while the earlier one was 17dB (which is the reason I compared it to my previous 16.7dB line).

Whatever they've done to get rid of the noise, they've added the equivalent of 100m of cable!

Of course, it could be longer, thinner, or made of aluminium. Or just harbouring a new fault, ready to pounce later.

Something's not quite right, anyway

That's because I replaced my router. Technicolor one, if I reconnect it, will report 17dB attenuation, while this Billion reports 22dB. The increase happened even before BT did anything.

Billion seems to report the attenuation more accurately than Technicolor one, as it seems to match what my line speed is.

Going to go for a walk to my cabinet to see which one it is. If it's Huawei, I am hoping for G.INP to be enabled soon (wishful thinking perhaps). Oh, and get a nice pasty from the bakers

One such fault in this area recently was caused by mice

On a ducted cable run maybe, but if a dig is required it's not a ducted route is it !

Saw WWW reply and went back to do some work. Then it occurred to me - is it the same modem? Which it is not and you have already found out the difference.

My cabinet - looks like a Huawei 288 to me. So, G.INP should be enabled sooner or later...

https://www.dropbox.com/s/l25vdxw4r98fw92/2015-09-18...

Sorry, should've said earlier when explaining how to find your cabinet, the codelook website will tell you the cabinet vendor - all cabinets in Yatton are Huawei.

It seems your cabinet went live April 9th, meaning it should be capable of G.INP now - it just takes a while to kick in. Probably be all sorted by next weekend, if not before.

Obviously your Billion needs the right firmware in order to do G.INP, so I'd check that out whilst waiting for the DLM.

Thanks, yep, found the cabinet physically, thanks to your top off and its twin about 50 metres away - definitely a Huawei. Will wait for G.INP to kick in and my Billion does support it. Actually, so does the Technicolor router so if that doesn't work, I can always try the other.

Been on nearly 41000kbps sync since Thursday, though it did resync once on Saturday morning to the same speed.

Also hoping that my interleaving drops as it's introducing an 8msec delay to downstream...

It took about a week for interleaving to be dropped in favour of g.inp when my local cabinet was upgraded to support it. Oddly, before it was enabled for g.inp, I didn't have interleaving on the line (at least to any great depth), but the line would drop out about once a day. After the Huwai cabinets were enabled it resynced at a lightly higher speed and then, after a couple of days it resynced at much lower speed with interleaving enabled (when it was wholly bulletproof). Then, after a week or so it resynced back to the higher speed and now goes about a week or more between resyncs (as I write it's over 11 days since the last one).