Thank again. That's good to know, even if I am not that concerned about retransmission on the upstream yet.
Waiting now for a fix to be applied to my line, as I am still using the ECI modem and understand that the fix should return speeds and latency back to what is was before the G.INP was applied.

Quote from: Matthew

Sorry for the delay  The fault was stuck on our suppliers systems but it has come back now. They're wanting to arrange a engineer to the property investigate further. We can try and push back to get a engineer to investigate externally but this may delay things by a couple of days.

Thanks, Matthew.
I've replied to the ticket.
If it helps for me to be involved then I can do that...
I'll even enjoy it if it turns out to be the same guy who installed next door 
Here are some stats from the Huawei modem which I've just swapped in for a reference:

[tt]
11 Jun 2015 17:49:47
xdslcmd profile --show
Modulations:
G.Dmt Enabled
G.lite Disabled
T1.413 Disabled
ADSL2 Enabled
AnnexL Disabled
ADSL2+ Enabled
AnnexM Disabled
VDSL2 Enabled
VDSL2 profiles:
8a Enabled
8b Enabled
8c Enabled
8d Enabled
12a Enabled
12b Enabled
17a Enabled
30a Enabled
US0 Enabled
Phone line pair:
Inner pair
Capability:
bitswap On
sra On
trellis On
sesdrop Off
CoMinMgn Off
24k On
phyReXmt(Us/Ds) Off/On
TpsTc AvPvAa
monitorTone: On
dynamicD: On
dynamicF: Off
SOS: On
Training Margin(Q4 in dB): -1(DEFAULT)
#

xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 4277 Kbps, Downstream rate = 27104 Kbps
Bearer: 0, Upstream rate = 4410 Kbps, Downstream rate = 28661 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
  VDSL Port Details   Upstream   Downstream
Attainable Net Data Rate:     4277 kbps     27104 kbps
Actual Aggregate Tx Power:   -  9.2 dBm     13.5 dBm
====================================================================================
  VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
  Line Attenuation(dB): 1.6 8.2 10.9 N/A N/A 4.7 9.8 15.4
Signal Attenuation(dB): 1.6 7.8 10.5 N/A N/A 5.9 9.7 15.4
        SNR Margin(dB): 5.7 5.7 5.7 N/A N/A 6.2 6.1 6.1
        TX Power(dBm): -21.9 -35.4 -9.6 N/A N/A 10.6 7.8 6.9
#


xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 4301 Kbps, Downstream rate = 27104 Kbps
Bearer: 0, Upstream rate = 4410 Kbps, Downstream rate = 28661 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.1 5.7
Attn(dB): 8.4 0.0
Pwr(dBm): 13.5 -9.3
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 154 127
M: 1 1
T: 0 55
R: 16 16
S: 0.1717 0.9209
L: 7968 1251
D: 16 1
I: 171 72
N: 171 144
Q: 16 0
V: 8 0
RxQueue: 18 0
TxQueue: 9 0
G.INP Framing: 18 0
G.INP lookback: 9 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 37050
OHFErr: 0 1
RS: 10884352 2037127
RSCorr: 0 1
RSUnCorr: 0 0
Bearer 1
OHF: 29260 0
OHFErr: 0 0
RS: 175191 0
RSCorr: 1 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 83798376 0
rtx_c: 1 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 28649 0
errFreeBits: 205388 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 25867357 0
Data Cells: 2299 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: 79 79
AS: 470
Bearer 0
INP: 46.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 12.71
OR: 0.01 20.13
AgR: 28777.41 4430.69
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
Bitswap: 20/20 127/127
Total time = 9 min 9 sec
FEC: 0 1
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 79 79
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 9 min 9 sec
FEC: 0 1
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 79 79
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes 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
Latest 1 day time = 9 min 9 sec
FEC: 0 1
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 79 79
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 = 7 min 49 sec
FEC: 0 1
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
[/tt]

Quote from: AndyH

To be clear though, the profile update only removes the automatic application of upstream interleaving, where a line does not support retransmission in the upstream. It does not disable retransmission on lines that are capable of supporting it on the upstream.

That doesnt appear to be the case -  The new rollout is removing G.INP from the upstream regardless of whether the line equipment supports it or not. 

Quote from: alext05

Thanks, Andy. What will happen if I replace incompatible gear - ECI modem, for example - with compatible, like Billion 8800N. Will it automatically detect the hardware and reapply G.INP on upstream? If so, will it happen immediately or will take some time?

Regardless if the new fix has been applied then the DSLAM should immediately recognise the new router as compatible. 
You may see recovery straight away, but in some cases (ie if the line has been banded) then it make take longer to recover.
If the fix has been rolled out to your line, then its unlikely that you will see G.INP on the upstream.  Our users are having it removed - about half have been done so far. 

Quote from: alext05

Thank again. That's good to know, even if I am not that concerned about retransmission on the upstream yet. Waiting now for a fix to be applied to my line, as I am still using the ECI modem and understand that the fix should return speeds and latency back to what is was before the G.INP was applied.

It may be worth while having a read of this.  
Interleaving is being removed, but Error Correction may still remain.   This should mean your latency will return to what it was previously, but the overheads for error correction mean that not all people are recovering their previous speed.   All lines are different and its impossible to know what yours will do.  

Thanks, kitz. You just answered something I was about to ask you. 
Is there a way of knowing whether the fix has been applied to a cabinet or not, apart from spotting the possible changes in latency and speed?

you could ask plusnet to post your line profile the new profile should say retransmission on the down but error correction off or low / high on the up , i'm pretty sure that's correct i'm sure Kitz or someone else will correct me if i'm wrong about that.

Quote from: Matthew

@mawdle As far as I'm aware the profile changes are being gradually rolled out and not all at once. With regards to the change you are correct as your line should resync. Your current profile is "0.128M-80M Downstream, Retransmission Low - 0.128M-20M Upstream, Retransmission Low"

As Kitz as pointed out you Andy H  are WRONG

Quote from: deathtrap

As Kitz as pointed out you Andy H  are WRONG

Eh? You've quoted a post that has nothing to do with me.

Quote from: kitz

That doesnt appear to be the case -  The new rollout is removing G.INP from the upstream regardless of whether the line equipment supports it or not.

I'm only reporting what's been briefed to ISPs from Openreach. They were quite clear that upstream retransmission is still available to DLM:

Quote from: AndyH

Quote from: deathtrap As Kitz as pointed out you Andy H  are WRONG Eh? You've quoted a post that has nothing to do with me. Quote from: kitz That doesnt appear to be the case -  The new rollout is removing G.INP from the upstream regardless of whether the line equipment supports it or not.   I'm only reporting what's been briefed to ISPs from Openreach. They were quite clear that upstream retransmission is still available to DLM:

And that is WRONG also I was Fully G.inp'd  Until this FIX /Botch and was using a Huawei Modem (Fully compatible device ) connected to a Huawei FTTC cab  as a result of this non fix rollout  i have lost 1-2mbps from upstream attainable rate thanks to higher FEC overheads, i was seeing a small benefit from G.inp  until this
as for this forum & quoting from someone eleses post that wasn't how i viewed it  whilst composing it so ?????? as the forum goes  i certainly did not select the user mawdle quote i selected yours and replied to yours,
 

andyh since you have that privileged access you might use it to tell them they giving out wrong information?

Contrary to what you, and some other people might think, the technical engineers/developers within Openreach aren't a bunch of clueless idiots. Many have extensive experience and knowledge of telecommunications/broadband engineering and know much more than any forum enthusiasts will ever know.
If you have specific examples of users that are not seeing DLM applying retransmission correctly, then you need to tell them to raise it through their ISP. There are appropriate channels that need to be followed; you cannot just approach Openreach and tell them they are giving out wrong or misleading information.

Hi Andy, I am guessing Plusnet would have access to the same Openreach information you have and should be able, in theory, as an independent source (I am not questioning your knowledge or independence here) to either confirm what you are saying is correct or not. I am surprised that they, so far, have abstained from commenting on the claim whether G.INP is indeed being disabled on upstream regardless of the compatibility of the equipment or should not be disabled for those with compatible equipment. I believe an authoritative ISP-led confirmation is long overdue.
Secondly, I am just wandering whether Plusnet can easily extract the data for those people who had a fix applied to see whether anyone at all has retained G.INP on upstream? Is this possible to do with access to Openreach dashboard, for example? Thanks for all you help.

Quote from: AndyH

If you have specific examples of users that are not seeing DLM applying retransmission correctly, then you need to tell them to raise it through their ISP. There are appropriate channels that need to be followed; you cannot just approach Openreach and tell them they are giving out wrong or misleading information.

Unfortunately, users cannot approach their ISP and tell them to fix their G.INP on upstream because, apart perhaps from you claiming it should be working with compatible equipment, they don't know whether it should be working or not. There is no authoritative information in public domain to confirm that it should be working and clearly some people lost it after the fix. How do they know it's not part of the fix?
Also, ISP customer support folks often don't know themselves what is going on on the wider network. When I approached Plusnet about lost speed and increased latency following the G.INPing of my line, no one mentioned G.INP and gave proper explanation. They said my line is performing as it should.