Kitz Forum

Announcements => Site Announcements => Topic started by: kitz on April 30, 2016, 02:26:16 PM

Title: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on April 30, 2016, 02:26:16 PM
As previously reported on kitz, we first noticed the nationwide roll out of G.INP/Retransmission to ECI cabinets (http://forum.kitz.co.uk/index.php/topic,17286.0.html) on the 17th of March.

We have been closley monitoring the progress of the roll-out, but by early April it was clear all was not well and some lines were experiencing issues which resulted in a high rate of faults being reported to Openreach and at this time we announced that ECI roll-out was being suspended and retransmission was being removed from some lines (http://forum.kitz.co.uk/index.php/topic,17447.0.html).

To date circa 260k lines have had retransmission removed, but unfortunately the fault rate is still much higher level than Openreach would expect, so last week Openreach took the decision to remove G.INP/retransmission for the vast majority of lines on their ECI network.

Phase 2 roll-back commenced 27th of April and is expected to be complete by next week. Openreach are continuing to monitor fault levels and are working with their vendor to find a permanent solution.  An update is due mid May.

Roll back in itself has not been without problems and already we have noticed stable lines which have never been interleaved having interleaving (http://www.kitz.co.uk/adsl/interleaving.htm) and Forward Error Correction (http://www.kitz.co.uk/adsl/error_correction.htm) applied, which has reduced line rates considerably to less than before G.INP was applied.  Conversely some other lines which obviously need Error Protection are left experiencing extremely high rates of Errored Seconds and are on an open DLM profile (http://www.kitz.co.uk/adsl/DLM.htm).   All-in-all its not going too great right now. :(
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: Chrysalis on April 30, 2016, 04:50:11 PM
thanks for the update, not good news.

It is strange given that most people who are posting on forums appeared happy with g.inp.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: simoncraddock on April 30, 2016, 04:59:10 PM
Since it was applied to my line several weeks ago my connection has been dropping every couple of days compared to every few months. I've just returned home from a weeks vacation to now find interleaving has been enabled, so I'm not happy with BT right now.

So now I'm currently waiting on Plusnet support to raise it with BT.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: Dray on April 30, 2016, 05:07:19 PM
It's not really up to the users to evaluate how the Openreach network is performing.I think Openreach are unhappy with the impact of ECI G.INP on their network and have decided not to live with it.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: Chrysalis on April 30, 2016, 05:22:32 PM
Dray true, but this is down to faults, a fault starts with a user reporting to their CP.

Ultimately from openreach point of view, the business case for g.inp is to reduce faults they have to fix.  It seems this rollout actually went the other way instead.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: WWWombat on April 30, 2016, 09:29:00 PM
Roll back in itself has not been without problems [...]  All-in-all its not going too great right now. :(

Too true.

a fault starts with a user reporting to their CP.

Not always. Indeed, in most of my professional life, most of the faults I've dealt with originate with the operator themselves, not the end-user. Appropriate use of OMC/NMS should give a proper overview of the statistics of large-scale behaviour.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 01, 2016, 12:14:12 AM
>> It is strange given that most people who are posting on forums appeared happy with g.inp.


These are likely those who know what is going on and have access to stats.    If they have access to full stats, then they are unlikely to be using the ECI modem/HH5A.

The FEC & Err/sec bursts that have been seen only since ReTX is also weird. 
Most people are reporting upstream bursts between 9-10pm.  Im seeing downstream bursts at ~ 10am.
Because there is no FEC on my downstream, it has to be something related to g.inp
 
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: Chrysalis on May 01, 2016, 07:00:56 AM
Not always. Indeed, in most of my professional life, most of the faults I've dealt with originate with the operator themselves, not the end-user. Appropriate use of OMC/NMS should give a proper overview of the statistics of large-scale behaviour.

Are you talking about the UK CPs tho?  AAISP are the only isp I am aware of that even actively monitors their customer line's, on plusnet e.g. people can have lines that are down for weeks and plusnet is unaware until the end user reports it.  Why would a CP report a faulty line to openreach if their customer appears to be happy?
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 01, 2016, 10:02:23 AM
I think wombat may mean Openreach/BT.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 01, 2016, 07:28:27 PM
Ive removed the info about multi-cast as it looks like they may have already made a decision on this and are removing it on those lines too.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: WWWombat on May 06, 2016, 12:36:27 AM
Ooops - sorry, I missed the question.

Not always. Indeed, in most of my professional life, most of the faults I've dealt with originate with the operator themselves, not the end-user. Appropriate use of OMC/NMS should give a proper overview of the statistics of large-scale behaviour.

Are you talking about the UK CPs tho?

I'm really talking about operators with their own infrastructure, and the network-management functionality to monitor it, or to perform self-test on it. Such operators are perfectly capable of observing a fault themselves, reporting it themselves, and fixing it themselves.

This is, of course, an issue way beyond the scope of just a fault with one copper access pair. But even that can be seen and fixed - BT have their own self-test hardware that can be deployed automatically.

My background is, however, more from the mobile world and seen from the equipment vendor perspective. At times, I've been involved with Vodafone, TMobile, and O2 in the UK, and plenty of other operators around the world. I still remember my first visit to one2one's network management centre, with many status screens across the wall - including all the indications of alarms from various pieces of hardware, or various links that had failed.

On the issue at hand, I would have thought that any decisions to trial, or subsequently roll out, G.INP on ECI DSLAMs would be run with monitoring of the resulting outcome. Some idea of how many subscribers got faster speeds vs lower speeds. Some idea of how many subscribers got fewer FECs vs higher FECs (same for ES, CRC etc). Given the delays, I'd expect people from Openreach, TSO and ECI to work hand-in-hand at both gathering those statistics, and analysing them for problems.

We know BT monitored the outcome for the Huawei estate, as we've seen graphs of a couple of outcomes:
(http://www.kitz.co.uk/adsl/images/retransmission_linespeeds.png)(http://s32.postimg.org/hc40s7u9x/G_INP_Results.png)
http://postimg.org/image/bnxq1bpxd/
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: WWWombat on May 06, 2016, 12:37:30 AM
Ive removed the info about multi-cast as it looks like they may have already made a decision on this and are removing it on those lines too.

This post looks a little strange when the info about multicast has already been removed. It made me wonder what the information used to be!
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: Chrysalis on May 06, 2016, 01:37:02 AM
thanks for the reply to my question, but given the approach openreach take to performance related faults, its a "best effort" basis and their engineers are instructed to not even check for speeds on things like pair swaps, the only thing that matters is sin compliance.  For that reason I would be surprised if openreach took it upon themselves to declare speed drops as faulty lines.  Given the statements we have had access to I am more inclined to think faults raised by end users is what has risen and to levels openreach (or/and the CPs) considered unacceptable.

My gut guess is the daily FEC spikes we have seen is on some modems causing disconnections and these disconnections are the trigger for the faults.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 06, 2016, 08:41:20 AM
@wombat.

Sorry, it originally said that they may not remove g.inp on those lines which had multi-cast (IPTV from their ISP) as those were the lines which would benefit most, but that they would make a decision on that in the next few days.  The day after they started removing it on those lines too.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 06, 2016, 08:51:49 AM
Mini-update

They are aware of the issue with the spike in errors. Apparently they have been aware of this for a (short) while.
The overwhelming issue though is the loss of PPP and intermittent sync problems. 

---
Interestingly an observation by me on the people who may be having these problems is with the older Draytek models (2850 and 2750) and also I happen to notice a few people with Fritz!boxes (7490).   I cant seem to find anything definite about the Fritz!box 7490 other than it has a Lantiq VRX chipset.


edited to add Draytek model nos
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: atkinsong on May 06, 2016, 08:56:39 AM
Interesting Kitz. I certainly had no problems with the VRX-288 based Draytek 2760.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 06, 2016, 09:37:52 AM
The Vigor 2850 series is the one with problems. 
Draytek are aware there is an issue and yet said they dont have any plans to release new firmware.  :(
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: Chrysalis on May 06, 2016, 12:15:37 PM
I suspect the loss of PPP is not a direct issue but indirectly caused by loss of sync, as ghost PPP connections can get stuck on short disconnections preventing a new PPP session.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: parkdale on May 06, 2016, 04:08:53 PM
Fritzbox 7490 and 3490 both have the Lantiq VRX288 chipset but use a VRX208 as the modem for ADSL / VDSL
as shown on link below

https://translate.google.co.uk/translate?hl=en&sl=it&u=http://www.hwupgrade.it/forum/showthread.php%3Ft%3D2696089&prev=search
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: atkinsong on May 06, 2016, 05:40:54 PM
I seem to remember a statement from Openreach a few months ago to the effect that only modems that have met SIN498 requirements would be supported from March 16th or thereabouts.
Draytek have SIN498 certification for the 2760 and 2860 range, both of which are current and VRX 288 based.

I don't think there is any chance of them trying to gain certification for their now defunct models.

I wonder if this openreach statement is related to the issues some people are seeing?
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: ejs on May 06, 2016, 07:51:15 PM
I don't think there's any xDSL related differences between the VRX-268 and the VRX-288. They both use the same VRX-208 (for the "Analog Front End and Line Driver"). They both use the same 5.X.X.X.X.X DSL firmware versions.

The Draytek 2850 does not use a Lantiq chip for the VDSL2 connection. The Lantiq firmware numbers in the Draytek 2850 release notes start with 2, indicating it has a Lantiq ADSL2+ chip from the Danube family. IIRC the 2850 has separate sockets for the ADSL2+ and VDSL2 connections, the VDSL2 chip is from a different company (Metanoia?).

Also, I always thought that the lack of PPP indicated a general inability to transfer any user data over the VDSL2 connection, and so something using DHCP instead to set up an IPoE link wouldn't work any better.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 06, 2016, 10:01:54 PM
Quote
The Draytek 2850 does not use a Lantiq chip for the VDSL2 connection. The Lantiq firmware numbers in the Draytek 2850 release notes start with 2, indicating it has a Lantiq ADSL2+ chip from the Danube family.

Apologies.   Just going off what someone said last year re G.INP 2015.
I know for a fact that someone contacted Draytek about it last year and their response at that time was no updated f/w on the cards.


Funny enough & complete co-incidence - Just spotted this (https://community.plus.net/t5/Fibre-Broadband/Draytek-2850n-Plusnet-FTTC-fibre-problem/td-p/1333315) which some one posted just a few hours ago on the PN Forum.   Wonder if he has ReTx on his line.

Quote
If I try to use the Draytek, it connects for a short while (seconds to minutes) then looses the connection. It has a ponder and then reconnects. Repeat.

He also shows his logs. 


Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: parkdale on May 07, 2016, 10:15:37 AM
I think his Draytek 2850 may be the first victim of the new BT Sin498 rules :no: after reading through it last night, says to the effect that any Modem/Router found on the network which does not carry certification, will be (more or less) blacklisted!, I believe the new rules came into effect as of April2016, Draytek themselves will not issue any update for it.
I see overclockers have drawn up a list of approved devices.
https://testvb.overclockers.co.uk/showthread.php?t=18718497
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: Dray on May 07, 2016, 11:39:08 AM
I think his Draytek 2850 may be the first victim of the new BT Sin498 rules :no: after reading through it last night, says to the effect that any Modem/Router found on the network which does not carry certification, will be (more or less) blacklisted!
Where does it say that?
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: parkdale on May 07, 2016, 01:13:27 PM
On Draytek's support site for MCT approval, look at section "what happens if I don't upgrade my firmware"

https://www.draytek.co.uk/information/our-technology/bt-sin-498?highlight=WyJidCIsImJ0J3MiLCInYnQnIiwiJ2J0Iiwic2luIiwiJ3NpbiIsNDk4LCI0OTgnIiwiYnQgc2luIiwiYnQgc2luIDQ5OCIsInNpbiA0OTgiXQ==
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: ejs on May 07, 2016, 01:35:04 PM
I think his Draytek 2850 may be the first victim of the new BT Sin498 rules :no: after reading through it last night, says to the effect that any Modem/Router found on the network which does not carry certification, will be (more or less) blacklisted!

If this were the case, then I think this would be concerning for all TP-Link VDSL2 models, which haven't been through the MCT testing, especially the TD-W9980 firmware which doesn't support vectoring.

BT wouldn't roll-back G.INP on ECI cabinets to accommodate devices that aren't compliant with SIN 498, that doesn't make sense if they are going to start strictly enforcing SIN 498 conformance testing.

I think it's more likely that it's just changes to the Openreach VDSL2 DSLAM firmware or configuration may result in older and not compliant devices no longer working properly. But not necessarily due to them being explicitly detected and cut off. There was a different problem a while ago, with a particular FritzBox model, I think the 7390, which uses an Ikanos chipset. It lost most or all of its upstream bandwidth except for the US0 band, until FritzBox fixed the problem with a firmware update.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: les-70 on May 08, 2016, 10:24:31 AM
I think it's more likely that it's just changes to the Openreach VDSL2 DSLAM firmware or configuration may result in older and not compliant devices no longer working properly.

   I agree, it seems logical that the issue must stem from the ECI DSLAM's as the Huawei DSLAM's have been successful albeit with the default of G.INP upstream removed to accommodate ECI /Lantiq modems not supporting upstream G.INP. 
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 08, 2016, 11:46:20 AM
Another "I agree".

There's too many of us on here with say Billions who havent had any problems.   
TBH, the only people Ive seen displaying the problems so far have been using older Drayteks and Fritz!boxes which is why a few days ago I started getting what the black cat would say as 'a tingle in my whiskers'.

Just this morning, Ive also seen another 3 possibles who said they were displaying odd symptoms - again these are Fritz!boxes and Drayteks. - link (http://forums.thinkbroadband.com/fibre/4480017-ginp-off.html?fpart=all&vc=1).  Ive not been doing any in depth analysis on models so perhaps someone else would like to do that..  its just the manufacturers names that Ive seen cropping up.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: les-70 on May 08, 2016, 01:20:37 PM
 I assume that the  older Drayteks and Fritz!boxes have no issues with the Huawei DSLAM.s so although those older devices may be finding the issue the issue must be quite DSLAM specific.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: Dray on May 08, 2016, 01:22:25 PM
I'm assuming they tried G.INP Mk1 on ECI cabs and now they'll do G.INP Mk2.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: ejs on May 08, 2016, 01:32:12 PM
I still don't think it makes any sense for BT to disable G.INP on all ECI lines because of what must be a comparatively very small number of FritzBox and Draytek devices. I think the vast majority of all end users will be using ISP supplied devices, plus I would have thought that the people who would buy a relatively expensive high-end device like a FritzBox or Draytek might also have a "free" ISP supplied device for testing or fault diagnostic purposes.

Or would they instead get offended at the suggestion that their 200+ device might be at fault?  ::)
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: skyeci on May 08, 2016, 02:24:38 PM
I think what will be highly unfair is if the eci g.inp gets abandoned. Still goes back to "we pay the same" yet users fortunate enough to not be on an eci cab in general get a better sync etc as we have seen prior to removal.
Perhaps eci users should get a discount  till its resolved if ever as its not a level playing field at the moment. I noticed looking up my town all the cabinets are eci .
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: ejs on May 08, 2016, 04:17:45 PM
And perhaps we should switch off all FTTC cabinets until FTTC/P is available everywhere. And rip out any FTTP and give them FTTC instead, otherwise that wouldn't be fair either. And limit everyone's broadband bandwidth to whatever the lowest universally available bandwidth is. I think some things like those would be the only way to make it a level playing field. :P Paying a variable price according to whatever speed you're getting each hour would probably be to complicated, but it's not fair that people paying the same price might get different speeds depending on how far away from their cabinet they are.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 08, 2016, 06:53:54 PM
I'm assuming they tried G.INP Mk1 on ECI cabs and now they'll do G.INP Mk2.

What is (was) done on the ECI's is (was) 'G.INP Mk2'.

Difference between Mk1 and Mk2 was Mk1 by default used upstream G.INP.  This caused devices such as the ECI modem which can only do downstream g.inp, to apply Interleave & FEC.   Hence the loss of 10Mbps of speed and high latency.

Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: Dray on May 08, 2016, 07:01:51 PM
I would have thought there is something in G.INP MK2 that can detect devices that don't support it and turn it off. I feel this is currently missing from the ECI implementation.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 08, 2016, 07:07:32 PM
I still don't think it makes any sense for BT to disable G.INP on all ECI lines because of what must be a comparatively very small number of FritzBox and Draytek devices. I think the vast majority of all end users will be using ISP supplied devices, plus I would have thought that the people who would buy a relatively expensive high-end device like a FritzBox or Draytek might also have a "free" ISP supplied device for testing or fault diagnostic purposes.

Or would they instead get offended at the suggestion that their 200+ device might be at fault?  ::)

I agree.  I wouldnt be surprised if there is some other (possibly ISP) modem somewhere.

The Draytek case I linked to above, had no problems when using the PN supplied router - just the Draytek.
I also asked Simon who had problems with his Fritz!box disconnecting if he saw the same issue with another modem, but didnt get a reply.
None of the 3 cases on TBB mentioned they'd tried other modems either.
 
I dont monitor the ISP forums, but Ive not seen any of the issues reported on an ECI modem anywhere.
I've seen one 'possible' HH5A on Plusnet (therefore may not have updated f/w?).

Ive just checked out the Sky forums - admittedly Ive only checked the first page..  but it will be something like this (http://helpforum.sky.com/t5/Fibre-broadband/constant-connection-drop-outs/td-p/2460905) that we are looking for - note how it suddenly started after 17th of March which is when rollout started..  then note someone else says 'me too'.   Details are scarce, but what if it's say one of the older Sky hubs...  may be another older ISP modem such as TT...  who knows?   
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: Dray on May 08, 2016, 07:12:54 PM
That sky router is supporting G.INP - bearer 1 in the log.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 08, 2016, 07:22:12 PM
I would have thought there is something in G.INP MK2 that can detect devices that don't support it and turn it off. I feel this is currently missing from the ECI implementation.

There is and always has been 2 issues (http://forum.kitz.co.uk/index.php/topic,15283.msg284199.html#post_ECI_modem_issue1).

Issue 1 is if the modem doesn't support retransmission properly in the downstream direction, then it will have problems with PPP.
     ~ This is why Openreach rolled out new firmware to both the ECI & Huawei modems during 2014/2015.
Issue 2 is if the modem doesnt support retransmission in the upstream then it will :-
     ~ G.INP Mk1 - Apply Interleave and FEC.  Resulting in loss of sync speed and high latency.  Previous default was upstream G.INP on
     ~ G.INP Mk2 - Leave upstream by default as Interleave off.   Only apply G.INP on upstream if the line needs it and if the modem can support.

It looks like by default Openreach have set their DSLAMS to enforce downstream retransmission.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: Dray on May 08, 2016, 07:35:48 PM
It looks like by default Openreach have set their DSLAMS to enforce downstream retransmission.
I still think there is something in addition to that which can detect the device does not support G.INP in the downstream and so it turns it off - this is what's missing on ECI cabs, or maybe it needs to be more aggressive.

Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: ejs on May 08, 2016, 07:37:37 PM
Ive just checked out the Sky forums - admittedly Ive only checked the first page..  but it will be something like this (http://helpforum.sky.com/t5/Fibre-broadband/constant-connection-drop-outs/td-p/2460905) that we are looking for - note how it suddenly started after 17th of March which is when rollout started..  then note someone else says 'me too'.   Details are scarce, but what if it's say one of the older Sky hubs...  may be another older ISP modem such as TT...  who knows?

The person who says "me too" is on ADSL2/2+ according to their logs, it must be Sky LLU using G.INP on the downstream, therefore it can't be the same Openreach FTTC issue.

It may be that we won't find out what the problem is from individual reports, perhaps Openreach have evaluated the overall performance from the DLM data collected, and found that since G.INP was enabled for the ECI cabinets, it has made something worse, I'm guessing it might have increased the amount of re-trains (DSL drop-outs), which wasn't expected.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 08, 2016, 08:29:49 PM
Quote
The person who says "me too" is on ADSL2/2+ according to their logs,

Didn't notice that with the 'me tooer' as I was only scanning  :-[.. but still doesnt take away the first post is the type of thing that would indicate an issue with g.inp on ECI.  The OP post was an example of the type of thing to look out for on forums.
We have definitely been seeing the PPP failures for some the drayteks.

Quote
I'm guessing it might have increased the amount of re-trains (DSL drop-outs), which wasn't expected.

All I can say is that Ive been told about 4/5 times now (and 2 different sources) that the main issue is PPP.
I can't quote everything direct but it is very clear that it is "Protocal (PPP) session type faults i.e. - unable to connect to the internet yet the VDSL service is in sync" & "PPP failures"

They are aware of the "spikes of impulse noise", but its the PPP which is the major concern as that is classed as service affecting.

I'm just trying to get info and pass on what I have to you guys :(
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: broadstairs on May 08, 2016, 08:33:08 PM
Looking at the situation with some of use on ECI cabinets who dont have issue which affect our use then I can only suggest that the problem is at the end user end with hardware which does not support G.INP and to my mind that means there should be a method of turning it off for those affected until their ISP can provide hardware which does support G.INP. OK that might mean some ISPs having to provide new modems but tough they make enough money out of end users to do this.

My line was up for 40 days continuously with no detectable performance affecting issues on an ECI cabinet and now I suffer because they pull it completely on the ECI estate.

Stuart
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 08, 2016, 08:37:35 PM
I would have thought there is something in G.INP MK2 that can detect devices that don't support it and turn it off. I feel this is currently missing from the ECI implementation.

The ECIs certainly seem more picky and this must be more of a serious problem to roll back totally.
Perhaps it can't detect if the EU equipment is compatible or not - I don't know. 

However, I do know last year the Draytek 2850 had the same issue with Huawei cabs.   This is a comment I got last year by someone who had been trying to get Draytek release new f/w for his 2850.. and upon being told in May 2015 they wouldnt.

"I got the 2850 in 2012 and had hoped it would have lasted longer than it has. With a retail value at the time in excess of 200 I'm surprised it's now going to be consigned to my kit box in the loft so soon :( "
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: licquorice on May 08, 2016, 09:24:18 PM
From G998.4


11.1.13 Retransmission Mode (RTX_MODE)
The RTX_MODE is a configuration parameter used to control activation of retransmission during
initialization.
This parameter has 4 valid values:
0: RTX_FORBIDDEN: ITU-T G.998.4 retransmission not allowed.
1: RTX_PREFERRED: ITU-T G.998.4 retransmission is preferred by the operator.
(i.e., if ITU-T G.998.4 RTX capability is supported by both XTU's, the XTU's shall select
ITU-T G.998.4 operation for this direction).

2: RTX_FORCED: Force the use of the ITU-T G.998.4 retransmission.
(i.e., if ITU-T G.998.4 RTX capability in this direction is not supported by both XTU's or
not selected by the XTU's, an initialization failure shall result).
NOTE Due to the optionality of ITU-T G.998.4 retransmission in upstream direction, the use of
RTX_FORCED in upstream may lead to initialization failure, even if the XTU is supporting
ITU-T G.998.4 (in downstream).
3: RTX_TESTMODE: Force the use of the ITU-T G.998.4 retransmission in the test mode
described in clause 10.4.
(i.e., if ITU-T G.998.4 RTX capability is not supported by both XTU's or not selected by
the XTU's, an initialization failure shall result).

I would have thought the only possible mode of operation would be Mode 1 where G.Inp is only initiated if supported.

I.e if G.Inp capability cannot be detected, it isn't implemented.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 08, 2016, 10:14:41 PM
iirc, ejs and I had a convo about the G998.4 modes last year?

There's a possibility that Openreach may be using RTX_FORCED (2) on the downstream because it appears to over-ride any setting that the EU may make on their equipment.   
As mentioned at the time, it also fits with ITU statement "an initialization failure shall result".. which is basically ECI modem Issue 1 (http://forum.kitz.co.uk/index.php/topic,15283.msg284199.html#post_ECI_modem_issue1).

Quote
8th Jan 2015: ECI modems with old firmware connected to a G.INP enabled DSLAM, will appear to have sync but are not able to complete the initialisation process or get a PPP session.

For the Huawei cabs - it looks like RTX_PREFERRED (1) is used on the upstream.   It will presumably be turned off for upstream on the ECI cabs.

----

Damn..  if I'd have thought sooner I could have tried turning it off on my modem to see what happens on an ECI cab. 
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: licquorice on May 08, 2016, 10:26:42 PM
Hmm, not sure about the forced mode on downstream as I'm sure G.Inp had been implemented on my cab before I updated my TP Link TD-W9980 to G.Inp capability. Surely if Mode2 had been implemented I would have lost service.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: Dray on May 08, 2016, 10:37:14 PM
So why not just set it to preferred on the downstream (and on the upstream on Huawei cabs)? Is it because the end-user modems are fibbing and claiming to support G.INP when they actually don't?
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 08, 2016, 11:29:51 PM
Hmm, not sure about the forced mode on downstream as I'm sure G.Inp had been implemented on my cab before I updated my TP Link TD-W9980 to G.Inp capability. Surely if Mode2 had been implemented I would have lost service.

iirc it was just doing G.INP in downstream direction (same as the ECI modem/HH5A). 
The TD-W9980 was seeing same >10Mpbs speed decrease and increased latency as the ECI modems and HH5A which also supposedly support downstream only. 

G.INP Mk1 tried to put users on upstream G.INP, which because the above 3 didnt do... it forced them to have a high rate of interleave and FEC applied.   The Openreach fix (http://www.kitz.co.uk/adsl/ginp-retransmission.htm) (aka G.INP Mk2) for the ECI modems and HH5A's, was simply to swap from G.INP/INP first to FAST mode first.   No changes were made to the DSLAMS.. just the way the DLM was configured.

The new f/w released by TP-link enabled g.inp support both up and down as can be seen from the beta test f/w where you could see it was enabled both on upstream and downstream (ndirection) - link (http://forum.kitz.co.uk/index.php/topic,15322.msg284883.html#msg284883).

Quote
nReturn=0 nDirection=0 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=1 bVirtualNoiseSupport=0 b20BitSupport=0
nReturn=0 nDirection=1 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=1 bVirtualNoiseSupport=0 b20BitSupport=0

nReturn=0 nChannel=0 nDirection=0 nNFEC=32 nRFEC=16 nLSYMB=16 nINTLVDEPTH=1 nINTLVBLOCK=32 nLPATH=0
nReturn=0 nChannel=0 nDirection=1 nNFEC=32 nRFEC=16 nLSYMB=16 nINTLVDEPTH=1 nINTLVBLOCK=32 nLPATH=0
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 08, 2016, 11:42:31 PM
So why not just set it to preferred on the downstream (and on the upstream on Huawei cabs)?

Million dollar question and easy solution IMHO.  However it seems Openreach doesnt like the fact that EU's may try change settings themselves.
They have got decidedly funny about anything which gives the EU some control.. they obviously dont want EU's to be able to turn it off if they have a modem that gives them that sort of control :(

Quote
Is it because the end-user modems are fibbing and claiming to support G.INP when they actually don't?

Not quite sure what you mean by that.  If its what I think you mean, then no.
If it didnt support it.. (on a Huawei at least) then you could find yourself in the same position as with the Draytek and the guy who had to assign it to the loft.  Its probably why Draytek are offering ~100 off a newer model if you trade in your Vigor 2850... and admitting defeat that g.inp wont work at all on those routers.
If you dont have the g.inp update for ECI modems.. its why also Openreach was warning about the PPP issue way back in Jan 2015.

ejs.. could probably answer better than me as he's been poking around f/w.

What quite doesnt tie up with me.. is how a full reset to open profile will give you a few days to supposedly download the updated ECI f/w.
Openreach appear to be forcing g.inp except on open profile..  so is it DLM forcing it rather than the DSLAM?   Something is.

Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: Chrysalis on May 09, 2016, 12:06:21 AM
It seems clear that a quick solution is to give the CPs (or the EU's) the ability to toggle g.fast off, that means it can be enabled again nation wide, but when end users ring their isp to report its broken, then the CP can turn it off on a per line basis, but as kitz said openreach seem obsessed with not giving out any form of control other than allowing an isp to choose one of 3 stability profiles.

They also probably wouldnt have this issue if they enforced what modems could be used on the network, instead of the free for all we have now.  With devices like the fritzbox and asus modems ignoring standards.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: Dray on May 09, 2016, 07:45:46 AM
What quite doesnt tie up with me.. is how a full reset to open profile will give you a few days to supposedly download the updated ECI f/w.
I thought OR had said they run a process to enable G.INP on a regular basis and will continue to do so.
Quote
Any new and refreshed lines are being moved over to the Retransmission policy each night and we will continue to trawl our Huawei estate each month to move new adds/DLM resets onto the new profiles ad infinitum.
and
Quote
If a line is reset then it will initially move back to interleaved downstream and fast mode upstream. Retransmission will be applied again after a few days.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: licquorice on May 09, 2016, 08:46:42 AM
Hmm, not sure about the forced mode on downstream as I'm sure G.Inp had been implemented on my cab before I updated my TP Link TD-W9980 to G.Inp capability. Surely if Mode2 had been implemented I would have lost service.

iirc it was just doing G.INP in downstream direction (same as the ECI modem/HH5A). 
The TD-W9980 was seeing same >10Mpbs speed decrease and increased latency as the ECI modems and HH5A which also supposedly support downstream only. 

G.INP Mk1 tried to put users on upstream G.INP, which because the above 3 didnt do... it forced them to have a high rate of interleave and FEC applied.   The Openreach fix (http://www.kitz.co.uk/adsl/ginp-retransmission.htm) (aka G.INP Mk2) for the ECI modems and HH5A's, was simply to swap from G.INP/INP first to FAST mode first.   No changes were made to the DSLAMS.. just the way the DLM was configured.

The new f/w released by TP-link enabled g.inp support both up and down as can be seen from the beta test f/w where you could see it was enabled both on upstream and downstream (ndirection) - link (http://forum.kitz.co.uk/index.php/topic,15322.msg284883.html#msg284883).

Quote
nReturn=0 nDirection=0 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=1 bVirtualNoiseSupport=0 b20BitSupport=0
nReturn=0 nDirection=1 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=1 bVirtualNoiseSupport=0 b20BitSupport=0

nReturn=0 nChannel=0 nDirection=0 nNFEC=32 nRFEC=16 nLSYMB=16 nINTLVDEPTH=1 nINTLVBLOCK=32 nLPATH=0
nReturn=0 nChannel=0 nDirection=1 nNFEC=32 nRFEC=16 nLSYMB=16 nINTLVDEPTH=1 nINTLVBLOCK=32 nLPATH=0

Ah, OK. I was under the impression that it didn't support G.Inp in either directiion until the firmware update.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 09, 2016, 09:47:52 AM
@Dray.
What I meant is.. if it was DSLAM configured, then how does 'open profile' over-ride it.

There now appears to be 2 different sorts of reset.
1.) That which sets Interleave on as default as described by Ian last year & what we see in most cases.
2.) Total reset back to Open Profile with absolutely no DLM configuration at all.  This lasts for about 48hrs max before the DLM does its thing.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: WWWombat on May 09, 2016, 01:32:04 PM
What quite doesnt tie up with me.. is how a full reset to open profile will give you a few days to supposedly download the updated ECI f/w.
Openreach appear to be forcing g.inp except on open profile..  so is it DLM forcing it rather than the DSLAM?   Something is.

I thought the general principle was that DLM sets out what ought to happen, with a variety of configuration property settings, including some minimums and maximums (and we don't get to see all of these), and the DSLAM follows a channel initialisation policy that attempts to maximise X, minimise Y (etc) within constraints set by those DLM configuration properties.

I think that a DLM reset, of either variety, fundamentally changes the set of DLM configuration properties to something that either a) turns G.INP off and turns interleaving off; or b) turns G.INP off, and turns interleaving on downstream. I haven't figured out why there might be two different starting points, or why they might be chosen.

When DLM "turns on G.INP", it makes another fundamental change to the configuration properties, that allows retransmission to activate (forced or optional? Interesting debate), but the DSLAM continues to follow a policy of minimisation/maximisation that gives it freedom to alter some of the detailed outcome. This freedom means that some chipset/modem implementations can end up with a different detailed outcome, even if DLM starts out asking for the same thing.

What gives DLM the ability to choose to "turn on G.INP" for a line?

I thought OR had said they run a process to enable G.INP on a regular basis and will continue to do so.

I think this is a process running "above" DLM - a new supervisor process whose job is to determine what options DLM is allowed to choose for an individual line. As far as G.INP/retransmission is concerned, it looks like the default setting here is: "don't consider" - that DLM (in it's nightly decision process) isn't allowed to even consider retransmission as one of the "solutions" to a line in ILQ-RED/CRIMSON/SCARLET.

The supervisor level might then take the responsibility of deciding whether the chipset/modem is one that requires a restriction of the retransmission options.

If there are two levels, then I wonder whether the two different kinds of DLM reset that we see depend on whether the reset is done at the lower (nightly) level, or the upper (supervisor) level.

I could see a reset at the lower level being one that removes retransmission as a "solution", and replaces it with interleaving. I could see a reset at the higher level being one that takes away all "solutions", so DLM (at the lower level) only has the option of an "open profile" left available.

Now, some of the behaviour we've seen over the last year - especially new lines being put to the back of the (long) queue before retransmission is even considered - suggests there is very much a second process involved. Whereas the original DLM worked every night, on every line, in parallel (and still looks to), the new aspects seem to work slowly, over some lines, in a nationwide pool. Something is definitely running to a bigger overview.

If there is a second "something" running, then it makes sense that it makes decisions very independently of the other, nightly, process.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: WWWombat on May 09, 2016, 01:33:50 PM
It seems clear that a quick solution is to give the CPs (or the EU's) the ability to toggle g.fast off,

I think it is probably something like a year-long round-trip between adding requirements to the IT systems for Openreach, to them being developed, tested, released and available to Openreach CP's. I'm not sure that counts as quick...
 
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: WWWombat on May 09, 2016, 01:38:10 PM
I can only suggest that the problem is at the end user end with hardware which does not support G.INP

Retransmission is designed with the option of 4 different framing modes, and modems/chipsets are free to choose which layer to implement the retransmission function in.

It could well be that the problem is made visible with modems/chipsets that have chosen different (but still correct) ways to implement G.INP, only to find a bug in the cabinet that was not being tickled by other (more numerous) chipsets during testing.

Edit: Make sense, lad!
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: Dray on May 09, 2016, 11:00:14 PM
I have just noticed that BT is rolling out firmware version 4.7.5.1.83.8.204.1.11 for the HH5A again. I wonder if this is to ensure that all connected HH5A's are updated before Openreach turn on G.INP on ECI cabinets again?
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 10, 2016, 09:57:43 AM

I think that a DLM reset, of either variety, fundamentally changes the set of DLM configuration properties to something that either
a) turns G.INP off and turns interleaving off;     or
b) turns G.INP off, and turns interleaving on downstream.

I haven't figured out why there might be two different starting points, or why they might be chosen.

Makes much more sense when phrased coming from that angle.
I was viewing from a different side of the triangle : Open was the basic setting..  then the options were Interleave or G.INP.

Something, somewhere appears to be set so that the EU cant over-ride G.INP via their modems. 

On a similarish topic.

Note how those of us say with BCM chipset based modems can no longer fiddle with SNRm to over-ride any target SNRm, when we could with previous DLMs.   What surprised me the other day is that I saw Simon say that he could do this via his Fritz!box.   Thats the first time Ive seen anyone able to do so..  usually we have to resort to capping speed.
It gets even more interesting when he says on the PN forum (https://community.plus.net/t5/Fibre-Broadband/G-INP-instability/m-p/1332261/highlight/true#M38087) as well as being able to set 4dB, 6dB, 8dB that his modem is cycling through different tone-sets.

Quote from: SIN 498
This involves supporting tone-sets A43 and A43C (as defined in G.994.1 Amendment 1).
The use of additional tone-sets (B43, B43c, V43) is not permitted as these may cause adverse interference to other DSL systems operating in the same cable binder.
snipped relevant bits or I'd be re-formatting too much pdf text

I'm beginning to understand just why MCT is needed. 
I think the ASUS also allowed something to be over-ridden that could be disadvantageous to neighbouring lines.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 10, 2016, 06:10:05 PM
...  and yet another Fritz!box :(

link (https://community.plus.net/t5/Fibre-Broadband/Struggling-to-sync-after-a-router-reboot-Fritz-Box-7490/td-p/1333990).
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: Chrysalis on May 10, 2016, 06:47:15 PM
just ban them. that fritz and the asus router/modem combo devices have been a nightmare really on FTTC.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: WWWombat on May 10, 2016, 06:56:48 PM
What is MCT?

I agree that BT's attitude towards overriding settings is all to do with the impact on neighbouring lines. As DLM gets 'smarter', it is moving away from single-line impacts to multi-line balancing - which is subverted by one user who knows better...

Also interesting to see tone-sets being cycled. It suggests the modem has delved into some strangely unused parts of the firmware...
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 10, 2016, 07:01:18 PM
MCT = Modem Conformance Testing (https://www.openreach.co.uk/orpg/home/products/super-fastfibreaccess/downloads/ProcessGuideforCPEeModemConformanceTestingIssue1.3.pdf)
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 10, 2016, 07:10:47 PM
@chyrs and @wwwombat

Cant recall what it was with the ASUS now but it was another nasty that could severely impact neighbouring lines.   
I think it was ability to ramp up the power, resulting in better SNR. Obviously I wouldn't want one of my neighbouring lines doing that :(
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: ejs on May 10, 2016, 07:20:45 PM
The tone-sets being cycled suggests to me that it's not configured appropriately for the Openreach network. How is the modem supposed to know which tone-sets it can and cannot use before or during the handshaking process? I'm not sure it can unless you configure it or the manufacturer configures it in the firmware for you.

Here is a comment in the AdslCoreDefs.h file from the Openreach HG612 source code release:
Quote
Revision 1.1.2.1  2010/01/07 03:49:11  l67944
Openreach OR357
The Huawei provided VDSL2 CPE (HG612) uses both A43c and V43 tone sets in its upstream handshake. Furthermore, upstream power back off is not applied in the V43 tones launched by the CPE. This means that the U/S handshake tones are violating the ANFP.

So Huawei had to adjust the HG612 firmware during development so that it did the right things.

The Lantiq dsl_cpe_pipe commands which include getting or setting the handshake tone-sets are llcg and llcs (low-level configuration get/set).

The ASUS modems have a setting in their GUI for enabling or disabling UPBO (Upstream Power Back-Off), if it were disabled, the upstream from a short line could adversely affect longer lines. And because people were having issues with it, they may have tried switching off and on all sorts of things, and most people can only observe how those settings affected their own connection.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: Chrysalis on May 10, 2016, 07:31:57 PM
@chyrs and @wwwombat

Cant recall what it was with the ASUS now but it was another nasty that could severely impact neighbouring lines.   
I think it was ability to ramp up the power, resulting in better SNR. Obviously I wouldn't want one of my neighbouring lines doing that :(

and the ignoring Upstream power cutback.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 10, 2016, 07:46:01 PM
Just had a look at the available settings (https://www.asus.com/support/faq/1015709/) - theres quite a few such as disabling PBO, adjusting GAIN etc.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: burakkucat on May 10, 2016, 07:59:39 PM
Cant recall what it was with the ASUS now but it was another nasty that could severely impact neighbouring lines.   

I have a vague memory that it was the ability of the EU to override the USPBO by a configuration option in the GUI.  :-\
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: parkdale on May 10, 2016, 08:09:07 PM
My Fritzbox 3490 is currently connecting using these settings. I have had BTOR out 6 times in last couple of weeks trying to sort out line noise (Voice).
Today is quite.
It's using tone set J43 that's interesting me, is their any advantages. have also seen A43 and A43c as well>
For a short time I was using G.inp
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 10, 2016, 10:10:02 PM
It gets quite complicated - although VDSL2 in the UK is Annex B, it shares some of the same tones as Annex A.
 
I think this is the latest document as it mentions additional support for G.INP and G.Vector.
Recommendation G.994.1 Handshake procedures for digital subscriber line transceivers (https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.994.1-201206-I!!PDF-E&type=items)

These are the VDSL2 profiles used by Openreach :

   ITU-T G.993.2 where support of a profile requiring US0 (Note 4)
   ITU-T G.993.2 with support of Annex B bandplan HPE17 or HPE30


So according to the specifications, it looks like it should only be using A43... or A43c which gives additional support for adsl2+ annex_M
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: kitz on May 10, 2016, 10:52:51 PM
Quote
It's using tone set J43 that's interesting me, is their any advantages.

J43 is intended for DSL over ISDN... not POTS.

According to this (https://en.wikipedia.org/wiki/G.992.3_Annex_J) tones normally reserved for voice are used for DSL.
"Annex J can not have POTS on the same line".

Quote
I have had BTOR out 6 times in last couple of weeks trying to sort out line noise (Voice).

 :hmm: :ouch:
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: WWWombat on May 11, 2016, 03:17:00 AM
MCT = Modem Conformance Testing (https://www.openreach.co.uk/orpg/home/products/super-fastfibreaccess/downloads/ProcessGuideforCPEeModemConformanceTestingIssue1.3.pdf)

Ah - Ta. Not an abbreviation Ive come across enough to stick in the grey matter.

As for everything else ... ugh. DLM gets a bad press, but subverting it is far worse. Perhaps we need that DLM supervision process to monitor for make/model, and start imposing a 2Mb/2Mb profile... that would be preferable to banning them.

It gets quite complicated - although VDSL2 in the UK is Annex B, it shares some of the same tones as Annex A.
 
I think this is the latest document as it mentions additional support for G.INP and G.Vector.
Recommendation G.994.1 Handshake procedures for digital subscriber line transceivers (https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.994.1-201206-I!!PDF-E&type=items)

These are the VDSL2 profiles used by Openreach :

   ITU-T G.993.2 where support of a profile requiring US0 (Note 4)
   ITU-T G.993.2 with support of Annex B bandplan HPE17 or HPE30


So according to the specifications, it looks like it should only be using A43... or A43c which gives additional support for adsl2+ annex_M

Sin 498 specifies A43 and A43c with the following quote:
Quote
The modem shall support operating with cabinet based VDSL2. This
involves supporting tone-sets A43 and A43C (as defined in G.994.1
Amendment 1[4]), plus downstream PSD shaping and upstream power
back-off as defined in G.997.1[5] and G.993.2[3]. The use of additional
tone-sets (B43, B43c, V43) is not permitted as these may cause adverse
interference to other DSL systems operating in the same cable binder.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: parkdale on May 11, 2016, 06:17:39 PM
Rebooted router today ... now on A43!! line still quite, although did see a burst of CRC errors at 3-4 in the morning.
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: WWWombat on May 11, 2016, 09:42:52 PM
Having checked G.994.1, I think the tone-sets only matter during initialisation - a way for modem and DSLAM to find each other. After that, things just run over the tones agreed at initialisation. (The medley?)
Title: Re: G.INP/Retransmission roll-out on ECI cabinets - UPDATE 30/04/2016
Post by: burakkucat on May 12, 2016, 12:04:09 AM
I think the terminology is discovery phase (during the initialisation) and medley phase (during "showtime").