Kitz Forum

Broadband Related => Broadband Technology => Topic started by: Ragnarok on April 09, 2015, 06:48:58 PM

Title: G.INP on ECI cabs
Post by: Ragnarok on April 09, 2015, 06:48:58 PM
So we know most Huawei cabs are mostly G.INP enabled.

Whats happening on the ECI front?

I've actually reconnected my ECI /R modem to insure it gets updated if they update them, even though the HG612 is better suited to my line but right now has little or no effect on my speeds/latency.
I've has some major work done  on an under ground cable and since then It looks like i've recovered my latency but i'm still banded at 67mbps on the downstream. The HG612 ECI / r comparison on my line currently is same latency, less than 1ms slower than the ECI /r but the ECI seems to have a better SNR (+1 db ) or a band plan favoring upstream, and a lower SNR or less bandwidth in the band plan allocated for the downstream.


Quote from: hg612
DSLAM/MSAN type:           IFTN:0xb204 / v0xb204
Modem/router firmware:     AnnexA version - A2pv6C038m.d24j
DSL mode:                  VDSL2 Profile 17a
Status:                    Showtime
Uptime:                    3 days 23 hours 25 min 5 sec
Resyncs:                   1 (since 13 Mar 2015 08:00:31)
         
            Downstream   Upstream
Line attenuation (dB):     17.0      0.0
Signal attenuation (dB):   Not monitored      
Connection speed (kbps):   66969      20000
SNR margin (dB):           7.8      8.5
Power (dBm):               13.6      5.9
Interleave depth:          1      1
INP:                       0      0
G.INP:                     Not enabled      

RSCorr/RS (%):             N/A      0.0384
RSUnCorr/RS (%):           N/A      0.0000
ES/hour:                   25.8      1.17

Quote from: ECI B-FOCuS V-2FUb r
name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.ModulationType] : value= [VDSL] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.LineEncoding] : value= [DMT] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.DataPath] : value= [Fast] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.InterleaveDepth] : value= [1] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.LineNumber] : value= [1] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.UpstreamCurrRate] : value= [20000000] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.DownstreamCurrRate] : value= [66996000] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.UpstreamMaxRate] : value= [25334120] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.DownstreamMaxRate] : value= [74822208] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.UpstreamNoiseMargin] : value= [93] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.DownstreamNoiseMargin] : value= [66] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.UpstreamAttenuation] : value= [ 0 ] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.DownstreamAttenuation] : value= [172] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.UpstreamPower] : value= [66] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.DownstreamPower] : value= [118] : found=[1]
Title: Re: G.INP on ECI cabs
Post by: Dray on April 09, 2015, 07:12:47 PM
I haven't heard of anything happening yet.
Title: Re: G.INP on ECI cabs
Post by: Chrysalis on April 09, 2015, 07:13:53 PM
according to our friend black sheep ECI rollout is starting this financial quarter, so anytime between now and end of june.

obviously tho this is subject to change as things dont always goto plan.
Title: Re: G.INP on ECI cabs
Post by: Black Sheep on April 09, 2015, 08:05:06 PM
Aye ....... the projection for the roll-out is shown as happening sometime now up to approx. 22/23 May. As Chrys has pointed out, these are only 'plans' and can be subject to radical change if an issue is highlighted. However, I haven't seen or been privvy to any such issues as yet. Hopefully it's still on target ???  :)
Title: Re: G.INP on ECI cabs
Post by: Ragnarok on April 10, 2015, 09:58:57 AM
Well taking my HG612 out of service has allowed me to get it upto date, just in case. I'll leave the ECi in place until G.inp arrives.
Title: Re: G.INP on ECI cabs
Post by: Bowdon on April 10, 2015, 10:47:21 AM
I wonder if the problems with getting the ECI modems working with g.inp on the Huawei cabinets have made BT cautious of the rollout on the ECI cabinets?

Is the ECI modem issue solved yet, or is it still on-going?

Though everything should be more smoothly on the ECI cabinets, technology can throw a spanner in the works sometimes, as BT have found out  :)

I hope those ECI issues get solved quickly.
Title: Re: G.INP on ECI cabs
Post by: stevebrass on April 10, 2015, 10:52:42 AM
What is involved in installing G.Inp on the ECI DSLAMs?

Title: Re: G.INP on ECI cabs
Post by: kitz on April 10, 2015, 04:55:19 PM
What is involved in installing G.Inp on the ECI DSLAMs?

G.INP itself is a software construct, although the chip itself needs to be powerful enough to cope with any additional processing/buffering.

----
Hmm  I just did some googling to see if I could find which Lantiq chip ECI used on the M41.  I couldn't find any info other than 'geminax'

So I started a google on that...   I didnt realise that Lantiq had their own version of PhyR since 2010
http://fastnetnews.com/dslprime/42-d/3637-lantiq-reducing-power-for-adsl-a-gpon

Quote
Lantiq has been strong in analog engineering since it was part of Siemens and Infineon.
They've now reduced the power and size of DSLAM chips with the 65 nanometer GEMINAX™ XXS V3

../snip/..

Lantiq supports retransmission on PHY level similar similar to Broadcom's PhyR

Similar?   I hope its compatible!  :D
Title: Re: G.INP on ECI cabs
Post by: stevebrass on April 13, 2015, 11:57:54 AM
A post on another forum - Thinkbroadband - quoting Openreach suggests that the ECI g.inp roll out is being tested and a full roll out is being considered.

BT OR apparently also express surprise that ECI modems have been supplied to customers on Huawei DSLAM's.
Title: Re: G.INP on ECI cabs
Post by: Ixel on April 13, 2015, 12:29:27 PM
A post on another forum - Thinkbroadband - quoting Openreach suggests that the ECI g.inp roll out is being tested and a full roll out is being considered.

BT OR apparently also express surprise that ECI modems have been supplied to customers on Huawei DSLAM's.

Argh, that sucks. 'Being considered', that might mean the rollout may not be underway this quarter then :(, or maybe not for a long while depending on how long they postpone this and whether they even do roll it out to ECI cabs in the end. Oh how I wish I was on a Huawei right now.
Title: Re: G.INP on ECI cabs
Post by: kitz on April 13, 2015, 02:00:40 PM
Quote
BT OR apparently also express surprise that ECI modems have been supplied to customers on Huawei DSLAM's.

We discussed this the other week and it would appear that the lefthand doesnt know what the right hand is doing :( 
The contractors have only been supplying ECI's for at least 18 months.  I know because I specifically wanted a Huawei, but the contractor told me he only had ECI's.  (They are white sticky labelled on the outside of the box )   

Black Sheep said moons ago that BT had decided that it didnt make any difference which modem was used with what dslam and said it didnt matter.  There was an official announcement which may be still knocking around if you search.   BS also confirmed recently that their supplies only had ECIs.


------------
btw.. out of interest I just dug out my ECI and I notice there it has a warranty - expiry date 06/2018.  5yrs warranty is a heck of a time, but doubt it would cover software. 
Title: Re: G.INP on ECI cabs
Post by: loonylion on April 13, 2015, 02:07:18 PM
BT OR apparently also express surprise that ECI modems have been supplied to customers on Huawei DSLAM's.

that's complete bullshit, my fibre was installed by a genuineR BTOR engineer, I am on a Huawei cab and was supplied with an ECI modem. I bought my own HG612.
Title: Re: G.INP on ECI cabs
Post by: Chrysalis on April 13, 2015, 03:25:50 PM
we know its bullshit but its either that they lieing to try and save face, or is as kitz said that one part of openreach doesnt know what the other part is doing.
Title: Re: G.INP on ECI cabs
Post by: Black Sheep on April 13, 2015, 03:58:48 PM
Quote
BT OR apparently also express surprise that ECI modems have been supplied to customers on Huawei DSLAM's.

We discussed this the other week and it would appear that the lefthand doesnt know what the right hand is doing :( 
The contractors have only been supplying ECI's for at least 18 months.  I know because I specifically wanted a Huawei, but the contractor told me he only had ECI's.  (They are white sticky labelled on the outside of the box )   

Black Sheep said moons ago that BT had decided that it didnt make any difference which modem was used with what dslam and said it didnt matter.  There was an official announcement which may be still knocking around if you search.   BS also confirmed recently that their supplies only had ECIs.

------------
btw.. out of interest I just dug out my ECI and I notice there it has a warranty - expiry date 06/2018.  5yrs warranty is a heck of a time, but doubt it would cover software.

All true, but a heads-up ..... we are again able to order either vendors modem for van-stock.  :)
Title: Re: G.INP on ECI cabs
Post by: burakkucat on April 13, 2015, 05:12:33 PM
Perhaps veering off-topic somewhat but I am always (1) critical (2) suspicious of any information that originates from Thinkbroadband. That does not mean that I totally ignore the output of Saffy and others but I do look very carefully at the original source -- if identifiable.
Title: Re: G.INP on ECI cabs
Post by: Bowdon on April 13, 2015, 09:01:36 PM
I didnt get a choice of modem. I had to get the HH5 (which apparently as the same problems the ECI modem has, and it was Kelly's who "installed" (I use that term very loosely!) my fibre connection.

I would suspect most people have the HH5, so I wonder how many are Type A like mine, and are now suffering problems.

Title: Re: G.INP on ECI cabs
Post by: Dray on April 13, 2015, 09:03:50 PM
I'd say the majority of HH5's are Type A and every one connected to a Huawei cabinet has an interleaved connection.
Title: Re: G.INP on ECI cabs
Post by: kitz on April 13, 2015, 09:07:34 PM
Perhaps veering off-topic somewhat but I am always (1) critical (2) suspicious of any information that originates from Thinkbroadband. That does not mean that I totally ignore the output of Saffy and others but I do look very carefully at the original source -- if identifiable.

I agree - its not Saffy I doubt.  In this case it would be the source. Probably someone who sits behind a desk all day and wouldn't know the difference between them, nvm seen one.
Title: Re: G.INP on ECI cabs
Post by: derekdel on April 14, 2015, 06:56:19 PM
Hi, First post be gentle :)

I have a ECI cabinet with an ECI modem.
I have read the posts on here on how to unlock HG612 modem and the not so easy way of unlocking the ECI modem.

I cant see the stats on my ECI modem so how will I know the update has been pushed through?
If I remove my ECI modem and fit the [ordered] HG612 modem I'm going to unlock will my original ECI modem still update at any time I reconnect it in the future?
Great forum by the way :)

Title: Re: G.INP on ECI cabs
Post by: kitz on April 14, 2015, 08:10:47 PM
Hi derek and welcome :)

Quote
I cant see the stats on my ECI modem so how will I know the update has been pushed through?

Very difficult. If you cant see your stats unless you notice an increase/decrease then you likely won't know. 

The 'incompatible' g.inp modems showed sufficient degradation of line facilities for people to notice.  Whether BT will put on hold plans to continue to roll out g.inp on the ECI's or not I dont know.  BT seem to be keeping very quiet atm and the only info we have seems to infer that one dept at BT doesnt know what another dept are doing.:(

Quote
If I remove my ECI modem and fit the [ordered] HG612 modem I'm going to unlock will my original ECI modem still update at any time I reconnect it in the future?

It will depend if it has the upgraded firmware or not.  Unfortunately because these modems are so locked down you have no way of knowing which f/w version is on there.  If it has the latest update ie to prevent Issue 1 (http://forum.kitz.co.uk/index.php/topic,15283.msg284199.html#post_ECI_modem_issue1), then I suspect it should be usable, but you will still see Issue 2 (http://forum.kitz.co.uk/index.php/topic,15283.msg284199.html#post_ECI_modem_issue2) until an update occurs.

Because so far all has gone quiet on the ECI rollout I think we may just have to wait and see what BT do next.   
Title: Re: G.INP on ECI cabs
Post by: derekdel on April 14, 2015, 08:37:27 PM
Thanks kitz
Title: Re: G.INP on ECI cabs
Post by: kitz on April 14, 2015, 09:05:45 PM
yw.   

I was at one point going to put my ECI modem on to see if it gets a f/w update, but because of its lower sync I didnt really want to leave it on for an unspecified time not ever knowing if it has upgraded or not.  Because Ive not used it for well over 18 months, Ive resigned myself to the fact it is now just a doorstop. :/
Title: Re: G.INP on ECI cabs
Post by: Ragnarok on April 15, 2015, 10:23:07 AM
Had an update on my ECI /r modem. I rebooted and left Btagent running, It's still unlocked too!!!!! Not sure if it's just a software update or G.inp implementation but my stats look significantly better than before. looks like some of the commands have changed.

The full termal view is in the txt my my stats have improved quite alot.

key things this appears on the terminal after logging in

 +-------------------------------------------+
 | Lantiq UGW Software UGW-5.4 on XRX288 CPE |
 +-------------------------------------------+

using the command

btagent_arc_version getstat


 name = [InternetGatewayDevice.DeviceInfo.SoftwareVersion] : value= [3.00.09] : found=[1]
 name = [InternetGatewayDevice.DeviceInfo.Manufacturer] : value= [Arcadyan Technology Corp] : found=[1]
 name = [InternetGatewayDevice.DeviceInfo.ModelName] : value= [BFocusV2FubR] : found=[1]
 name = [InternetGatewayDevice.DeviceInfo.ModemFirmwareVersion] : value= [5.6.7.5.1.6] : found=[1]
 name = [InternetGatewayDevice.DeviceInfo.AdditionalSoftwareVersion] : value= [0.09] : found=[1]


and key stats

name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.DataPath] : value= [Fast] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.InterleaveDepth] : value= [1] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.UpstreamCurrRate] : value= [20000000] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.DownstreamCurrRate] : value= [67000000] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.UpstreamMaxRate] : value= [24995342] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.DownstreamMaxRate] : value= [75245248] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.UpstreamNoiseMargin] : value= [89] : found=[1]
 name = [InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.DownstreamNoiseMargin] : value= [83] : found=[1]

Edit thinks to EJS and currytop I was able to figure out how to find details on how to check the if G.INP is enabled, I think it's in the bReTxEnable label.  These are exactly what i entered at the command line from the # and the output.

root@ltqcpe:~# /opt/lantiq/bin/dsl_cpe_pipe.sh "lfsg 1"
nReturn=0 nDirection=1 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=0 bVirtualNoiseSupport=0 b20BitSupport=0

root@ltqcpe:~# /opt/lantiq/bin/dsl_cpe_pipe.sh "lfsg 0"
nReturn=0 nDirection=0 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=0 bVirtualNoiseSupport=0 b20BitSupport=0

Looks like just a software update so far!!

I wonder if there is an update  for the ECI /b stashed away too to, but it's been left to rot.
Title: Re: G.INP on ECI cabs
Post by: kitz on April 15, 2015, 12:58:31 PM
Thanks ragnarok.

Can I just confirm that when you say you had an update, that you mean the modem had been in use for a while and should have previously been up to date.. and that a brand new update was rolled last nite?
Title: Re: G.INP on ECI cabs
Post by: Ragnarok on April 15, 2015, 02:06:21 PM
For clarity,

I normally ran a HG612 and this had been on the shelf for a long time. I put this modem back in to make sure it caught any ReTX/G.INP updates. When I do run this modem I normally have bt Agent disabled. I tried all last week to get bt agent to run via the command line  ( /bin/sh /BT/BTAgent/RO/btagentstart.sh ) but it crapped out after a day and never updated, no matter how many times I tried.

I rebooted on Monday, left bt agent running finally got an update this morning around 4am. The update also did not affect the unlocking of telnet access to the modem. I access the modem using DDWRT and a subnet access to the modem.

I'm not sure when this update started rolling out, but the update is out there. It looks ready for ReTx.

Also, the /opt/lantiq/bin/dsl_cpe_pipe.sh "lfsg 1" and /opt/lantiq/bin/dsl_cpe_pipe.sh "lfsg 0" commands definitely did not work before the update.

In future I won't be disabling btagent on the ECI. I may keep it in as the line looks like it has more SNR margin than than HG612 after last nights update.
Title: Re: G.INP on ECI cabs
Post by: kitz on April 15, 2015, 08:23:08 PM
Thanks for the clarification :)
Title: Re: G.INP on ECI cabs
Post by: NewtronStar on April 15, 2015, 10:41:09 PM
So it just a normal update to firmware as the ECI modem has been out of commission for over a year or so  :-\
Title: Re: G.INP on ECI cabs
Post by: Ixel on April 16, 2015, 01:21:05 AM
This isn't nothing new. I've also seen the above (retx stuff) on mine some months ago unfortunately. However, another update soon or very recently is possible.
Title: Re: G.INP on ECI cabs
Post by: Dray on April 16, 2015, 01:32:30 AM
Someone has already announced it as a "fact" https://community.bt.com/t5/BT-Infinity-Speed-Connection/G-INP-affecting-certain-eci-modems-resulting-in-a-drop-in-sync/m-p/1472805/highlight/true#M175223
Title: Re: G.INP on ECI cabs
Post by: Ragnarok on April 30, 2015, 09:15:44 PM
I'd say it's more likely, the modem looks like it's behaving better. Some commented that having seen RETX enable=1 and

Considering the issues most vendors are having with lantiq hardware and making it fully compatible with G.inp, it's highly unlikely even in co-operation with lantiq BT got this update right first time, the update may be an old one too which would make it even more likely there are RETX incompatibilities.

I find this whole G.inp situation bizarre, it sounds like it's the norm for many other networks around the world. We know BT like to be slow and get it right, heck they even set stringent standards that modems/routers had to meet, but still ended up having big issues with lantiq hardware. I'm amazed the ECI modem issues never came up in testing, and it never crossed their minds that Lantic/ECI modems might be used on Huawei cabs and tested anyway.

There are some round here who seem to have a much better grasp of the issues than BT's PR department anyway, BT's also huge so it's probably a bureaucratic nightmare to get anything done or rolled out, I can imagine many of there technicians/engineers know exactly what's happening and are just as frustrated as some of us are.
Title: Re: G.INP on ECI cabs
Post by: Ragnarok on April 30, 2015, 09:30:06 PM
I'd say it's more likely, the modem looks like it's behaving better. Some commented that having seen RETX enable=1 and

Considering the issues most vendors are having with lantiq hardware and making it fully compatible with G.inp, it's highly unlikely even in co-operation with lantiq BT got this update right first time, the update may be an old one too which would make it even more likely there are RETX incompatibilities.

I find this whole G.inp situation bizarre, it sounds like it's the norm for many other networks around the world. We know BT like to be slow and get it right, heck they even set stringent standards that modems/routers had to meet, but still ended up having big issues with lantiq hardware. I'm amazed the ECI modem issues never came up in testing, and it never crossed their minds that Lantic/ECI modems might be used on Huawei cabs and tested anyway. I would of thought they would of also thoroughly tested ECI cabinets before deploying them too.

There are some round here who seem to have a much better grasp of the issues than BT's PR department anyway, BT's also huge so it's probably a bureaucratic nightmare to get anything done or rolled out, I can imagine many of there technicians/engineers know exactly what's happening and are just as frustrated as some of us are, especially if we're all waiting on Lantiq for a fix.
Title: Re: G.INP on ECI cabs
Post by: kitz on May 01, 2015, 12:46:03 AM
For all intents and purposes it looks like their testing was silently roll it out to a few cabs in and around the Martlesham Heath area.   The testing was also done before any of the changes they made to the DLM late last year after the ASSIA case.  Its also possible if those cabs were the early enabled bunch (ie pre2013) that modems may have been matched to cabs.   I am surprised they didnt pick up some sort of inkling that something was wrong though.

>> it sounds like it's the norm for many other networks around the world.

In the other main thread I posted a link to another ISP, but it was in German and even with the aid of google translate I couldnt get a proper understanding what was going on, but it does appear they may have also had a similar issue with the lantiq chipsets earlier this year.
Title: Re: G.INP on ECI cabs
Post by: Mark07 on May 01, 2015, 02:44:39 PM
Spotted an OR engineer in my ECI fibre cab (not the PCP, the actual fibre cab) on my way to work this morning, as I'm aware for customer connections etc they don't go into the fibre cabs themselves, so could it be they were installing some new hardware in there?  :)
Title: Re: G.INP on ECI cabs
Post by: loonylion on May 01, 2015, 02:52:53 PM
Spotted an OR engineer in my ECI fibre cab (not the PCP, the actual fibre cab) on my way to work this morning, as I'm aware for customer connections etc they don't go into the fibre cabs themselves, so could it be they were installing some new hardware in there?  :)

probably a heating pad :P
Title: Re: G.INP on ECI cabs
Post by: Mark07 on May 01, 2015, 03:34:37 PM
Yeah that's what I was thinking, something totally unrelated and uninteresting  :D no change to my stats either
Title: Re: G.INP on ECI cabs
Post by: burakkucat on May 01, 2015, 05:00:19 PM
probably a heating pad :P

Or removing the Mossad installed "back-door"?  :D
Title: Re: G.INP on ECI cabs
Post by: Mark07 on May 02, 2015, 04:26:06 PM
Or the cat6 I installed  :-\
Title: Re: G.INP on ECI cabs
Post by: themanstan on June 01, 2015, 07:32:22 PM
https://community.bt.com/t5/BT-Infinity-Speed-Connection/G-INP-affecting-certain-eci-modems-resulting-in-a-drop-in-sync/m-p/1487001#M178832

3rd post from bottom on p37. appears a fix is coming out...
Title: Re: G.INP on ECI cabs
Post by: kitz on June 01, 2015, 07:46:40 PM
Thanks for that ^, but I think what SeanD actually meant is that its for those on the Huawei cabs.

Quote
Thank you for your continued patience.  As you know Openreach recently carried out a trial to address the reports on this thread with regards to G.INP.  Openreach are very happy with the results of the trial and after some consultation they have now decided to roll this fix out across the network.

The trials were only on Huawei cabs and theres been no definite news yet about the ECI cabs other than a review after the Huawei's have all been updated.  Im guessing here but I should think that will be late July before we hear anything more definite about the ECI's.

As regards to the 'fix' it may not be all wonderful for the ECI modems.  Interleaving appears to have been turned off, but from what Ive seen so far Error correction is still being applied which means no recovery of the loss of speed.    However we are waiting for the Huawei rollouts and then some kind soul such as BaldEagle will be able to test properly with stats to see whats happening.    Its not something I can do myself as Im on an ECI. :'(
Title: Re: G.INP on ECI cabs
Post by: Chrysalis on June 18, 2015, 12:11:04 PM
kitz I post my 3 day montage for your viewing pleasure, cannot find our most recent posts, but this thread seems appropriate.

Since that resync event I have higher bitswapping and higher ES on my upstream, the ES rate on the DS is ok, but I have had 3 SES.

Title: Re: G.INP on ECI cabs
Post by: kitz on June 18, 2015, 08:03:18 PM
Im not sure what to make of it.   Your power is different, so that would account for the slightly less max attainable upstream,  and could cause more bitswap and errors, so I cant really draw anything conclusive to say a prep for g.inp (other than downtime).   It's not unusual for power to change upon a resync as the bitswap process can eventually cause power output to go up.. which then goes back down again at a fresh resync.
 
afaik the g.inp software config changes at the dslam should make any difference to your line conditions and its only when stage two is applied that you start seeing its effects.
Title: Re: G.INP on ECI cabs
Post by: simoncraddock on June 18, 2015, 08:13:36 PM
Your line is behaving in a similar fashion to how mine was Friday morning after a DLM resync around 3am. Afterwards I had steady stream of both CRC and ES errors from the moment it resynchronised which lasted around 30hrs before it lost connection twice in quick succession mid Saturday morning applying quite heavy interleaving.

At first I put it down to my newly installed Solar Panels but over the past few days I'm not so sure.

At the moment errors are really low but until interleaving is removed I can't really say if it's stabilised. Data as been uploading to MDWS for almost 48hrs so I can look for any pattern of errors that can possibly be explained.
Title: Re: G.INP on ECI cabs
Post by: NewtronStar on June 18, 2015, 09:11:37 PM
Well kitz if ECI cabs are to get G.INP the stage 1 should already be on the way to update cabinets and some of the Huawei users did notice strange going on's before the start of stage 2.
Title: Re: G.INP on ECI cabs
Post by: Semmy on June 19, 2015, 08:18:15 PM
Spotted an OR engineer in my ECI fibre cab (not the PCP, the actual fibre cab) on my way to work this morning, as I'm aware for customer connections etc they don't go into the fibre cabs themselves, so could it be they were installing some new hardware in there?  :)
Could always be an incremental tie job.
Title: Re: G.INP on ECI cabs
Post by: Mark07 on June 19, 2015, 09:01:51 PM
Could have been anything I guess, but nothing has changed on my line  :(
Title: Re: G.INP on ECI cabs
Post by: Chrysalis on June 24, 2015, 03:25:51 PM
another odd resync around 1-2am yesterday, I had monitoring off at the time tho as was reworking my lan, my power levels have reverted.
Title: Re: G.INP on ECI cabs
Post by: Mark07 on June 24, 2015, 03:55:51 PM
I had my first resync in 17 days in the early hours, nothing appears to have changed though  ::)
Title: Re: G.INP on ECI cabs
Post by: Chrysalis on June 26, 2015, 04:15:48 PM
as expected since my power increased again the SES have stopped. Averaging 2-3 ES a day on upstream. Please leave ECI US alone openreach if g.inp comes to ECI.
Title: Re: G.INP on ECI cabs
Post by: Oldjim on July 09, 2015, 02:26:17 PM
Probably not the right place - please move if appropriate - just had fibre install on a Huawei Cab and all the BT engineer had were ecl modems
Title: Re: G.INP on ECI cabs
Post by: stutaylor on July 17, 2015, 01:45:05 PM
I see from other posts a lot of hauwei cabs are now on mk2, any chance of BT doing the ECI cabs this year?  :fingers:
Title: Re: G.INP on ECI cabs
Post by: burakkucat on July 17, 2015, 05:59:54 PM
I see from other posts a lot of hauwei cabs are now on mk2, any chance of BT doing the ECI cabs this year?  :fingers:

That is the aim, of which I am sure.  :)
Title: Re: G.INP on ECI cabs
Post by: Terranova667 on July 17, 2015, 06:38:01 PM
I see from other posts a lot of hauwei cabs are now on mk2, any chance of BT doing the ECI cabs this year?  :fingers:

I have read on the Plusnet forum that the ECI cab testing is done and the rollout is imminent, whether that is true or not i can't say for sure black Sheep did mention maybe August, so yeah there maybe hope for us ECI cab users just around the corner, fingers crossed it doesn't go the way of the Hauwei cabs with a unseen issue and further delays.     
Title: Re: G.INP on ECI cabs
Post by: Chrysalis on July 17, 2015, 06:39:04 PM
We will soon find out if its another cock up.

The likes of me and kitz wont sit silent if they bodge it up for sure. As rightfully we dont want our lines to regress, both of us are stable on fast path.
Title: Re: G.INP on ECI cabs
Post by: NewtronStar on July 17, 2015, 06:49:05 PM
We will soon find out if its another cock up.
The likes of me and kitz wont sit silent if they bodge it up for sure.

And remember the Huawei users have had to sacrifice G.INP on the Upstream so ECI modems & cabinet users can get G.INP so OpenReach don't mess this up or you will get a thump  ;)
Title: Re: G.INP on ECI cabs
Post by: Bald_Eagle1 on July 18, 2015, 05:48:40 AM
FWIW, a couple of users in the PlusNet Community forum have recently been claiming that US G.INP has now been restored.

http://community.plus.net/forum/index.php/topic,136287.msg1248954.html#msg1248954
Title: Re: G.INP on ECI cabs
Post by: kitz on July 18, 2015, 12:16:02 PM
Cheers BE1

Quote
ust checked stats on my Vigor, and after being removed on upstream for 2 weeks, G.INP has been re-enabled on upstream.
So just to confirm again, as of writing this I have working G.INP on both upstream and down stream!

That simply confirms what I've been saying on here for the past month or so will happen.  IE that G.INP on the upstream will be enabled if (1) DLM detects the line is unstable and needs it and (2) the equipment is G.INP compatible. 
Its why Ive been saying G.INP Mk2 is a much fairer solution and why BT are happy with the fix they put in place.

Title: Re: G.INP on ECI cabs
Post by: kitz on July 18, 2015, 12:47:18 PM
I have read on the Plusnet forum that the ECI cab testing is done and the rollout is imminent, whether that is true or not i can't say for sure black Sheep did mention maybe August, so yeah there maybe hope for us ECI cab users just around the corner, fingers crossed it doesn't go the way of the Hauwei cabs with a unseen issue and further delays.   

I was half way through making a post yesterday in the main g.inp thread about the August date, when I had to drop everything when Zigs started vomiting blood.   Post got forgotten about as I dashed off.   I'd found the references to the dates my earlier postings, but tbh cba to go searching again right now.. but they are there on this forum if you want to check.
 
Anyhow the abandoned post started off saying something like...   The info I have is that the ECI situation would be reviewed when the all the Huawei cabs had been completed which was estimated to be mid to end of July.   I got the impression from talking to someone very senior in BT that they were entirely happy that the fix implemented (g.inp mk2) and that it was working well.  What he wouldnt outright give was a date for starting the ECI rollout, although I had hinted in one of my posts about a month ago that it could be Aug/Sept.

However bearing in mind that the original plan was to commence rollout of the ECI's as soon as the Huawei's had been completed and that BT are saying they are happy with [MK2] G.INP on the Huaweis... it is possible that the review wont take long and they have already made up their minds. (I'm sure Ive said that before too).   Plus we have recently seen G.INP MK1 removed from one of our members who lives in Martlesham Heath where they have been testing G.INP on ECIs, it could mean they are prepping up for an imminent MK2 release for the ECI's.

All this and the timescales fit and tie in very nicely with the info is coming from BlackSheep too who as far as Im concerned hasn't been wrong with facts yet,  so yep although I dont have an exact date all the indications are that ECI's could be happening quite soon.
Title: Re: G.INP on ECI cabs
Post by: stutaylor on July 20, 2015, 01:52:31 PM
Hope so kitz, I'm already a long way from my Cab as it is and have notice a drop of 5mbits since I originally got installed in January, bringing me down to 30Mbits down, 5.8 Up.  More annoying is I have a cab < 150 metres from my property however i'm on a cab 450 metres away (walking distance along the footpath) as that's just how the phone lines are ran, infact I'm the last street on the main road that is on that cab before it jumps to the next one.
Title: Re: G.INP on ECI cabs
Post by: Bald_Eagle1 on July 24, 2015, 05:15:20 PM
That simply confirms what I've been saying on here for the past month or so will happen.  IE that G.INP on the upstream will be enabled if (1) DLM detects the line is unstable and needs it and (2) the equipment is G.INP compatible. 
Its why Ive been saying G.INP Mk2 is a much fairer solution and why BT are happy with the fix they put in place.



Quick update to this..........

It seems that reinstatement of US G.INP isn't a permanent measure (Huawei cabinet):-

http://community.plus.net/forum/index.php?topic=136287.msg1252342#msg1252342

Title: Re: G.INP on ECI cabs
Post by: Chrysalis on July 24, 2015, 07:52:59 PM
no ECI activity I take it?
Title: Re: G.INP on ECI cabs
Post by: NewtronStar on July 24, 2015, 09:18:24 PM
That simply confirms what I've been saying on here for the past month or so will happen.  IE that G.INP on the upstream will be enabled if (1) DLM detects the line is unstable and needs it and (2) the equipment is G.INP compatible. 
Its why Ive been saying G.INP Mk2 is a much fairer solution and why BT are happy with the fix they put in place.



Quick update to this..........

It seems that reinstatement of US G.INP isn't a permanent measure (Huawei cabinet):-

http://community.plus.net/forum/index.php?topic=136287.msg1252342#msg1252342

Well BE1 i have not witnessed any lines UpStream moving off fastpath to G.INP since the Mk2 rollout began there are odd cases but it's not mainstream.
Title: Re: G.INP on ECI cabs
Post by: kitz on July 24, 2015, 09:36:20 PM
That simply confirms what I've been saying on here for the past month or so will happen.  IE that G.INP on the upstream will be enabled if (1) DLM detects the line is unstable and needs it and (2) the equipment is G.INP compatible. 
Its why Ive been saying G.INP Mk2 is a much fairer solution and why BT are happy with the fix they put in place.



Quick update to this..........

It seems that reinstatement of US G.INP isn't a permanent measure (Huawei cabinet):-

http://community.plus.net/forum/index.php?topic=136287.msg1252342#msg1252342

Cheers for that BE, although I really dont see what the big mystery is about it over there.   As I keep saying
 
Its still there if DLM deems the line needs it and if the hardware is compatible


Its just one of the available config options available..   so the fact its gone again then DLM must have considered the line stable.
   
Just like with interleaving,  first time you may only get it for a couple of days, but if the line goes unstable again it will switch it back off.   
Same as with the other options such as interleaving, if the line flaps again it will go back on again, only next time for longer, until it gets to the point when its practically permanently on. 





*(attempts to refrain banging head on desk because Im beginning to feel like a stuck record)
Title: Re: G.INP on ECI cabs
Post by: NewtronStar on July 24, 2015, 09:43:22 PM


Its still there if DLM deems the line needs it and if the hardware is compatible



The Guys and Girls would like to see this happen in realtime over here on someones line to be sure this is the case !
Title: Re: G.INP on ECI cabs
Post by: kitz on July 24, 2015, 10:26:14 PM
Ive seen it on lines since about the 12th from elsewhere, but if you do want to see it 'here'  then here's a couple for you

From MDWS a couple that have what appears to be Mk2 g.inp upstream   (Not a leftover from Mk1):-

chouse had it, then it went off and then its back again.   An indication that its not Mk1 because otherwise it would have been permanently on.  Mk1 went on and stayed on, if it came off for anything such as line reset then it could only be Mk2 thats put it back on. 


Also Alec R who has a problematic line had it turned on a few days ago..  his cab went live in June, so one of the latter batch which will have gone straight to G.INP Mk2.  With his line being a bit erratic DLM has obviously decided he needs it.

54 on the downstream and 42 on the upstream :)

You can see on the attached MDWS screen grab that not only is G.INP turned on for the upstream, but its busy doing doing retransmitting of data for both up and downstream.   

Compare to someone like jelv who also has Mk2 g.inp turned on for downstream only, but look at his retransmits - practically zilch.  Jelv has a good short line and doesnt really need g.inp at all.
Title: Re: G.INP on ECI cabs
Post by: NewtronStar on July 24, 2015, 11:16:20 PM
If you are going to use AlecR as an example i have looked back 60 days and his US errored seconds were non-existent when interleaved and still non-existent after G.INP was enabled i would not call that a problematic line to issue G.INP on the Upstream ok maybe 2 blips in 60 days
Title: Re: G.INP on ECI cabs
Post by: kitz on July 24, 2015, 11:31:51 PM
But interleaving and Error Correction was switched off when G.INP was applied.   
So in other words the DLM knows that his line needs something.   It wouldnt have applied Interleaving if the line was hunky dory and it was the interleaving and error correction that was keeping the Err/Secs down.

Its not clear at the present time on the new system whether G.INP is a step down from interleaving and ErrCorrection, but I would imagine since we know that DLM can apply a mix of G.INP, FEC Error Correction & Interleaving, and we know that G.INP is the lesser evil, so its a non-brainer to deduce that DLM will apply G.INP first and if still not stable then apply FEC/Interleaving.

There must be something/ some counter in Alec's stats that prevented the DLM from completely removing FEC&Interleaving, but instead has applied the middle ground of G.INP.   If Alec's line was completely OK then DLM would have removed upstream G.INP.
We can see from his data that he is making use of retransmitted data on both up and down.
Title: Re: G.INP on ECI cabs
Post by: NewtronStar on July 25, 2015, 01:00:54 AM
There must be something/ some counter in Alec's stats that prevented the DLM from completely removing FEC&Interleaving, but instead has applied the middle ground of G.INP.   If Alec's line was completely OK then DLM would have removed upstream G.INP.
We can see from his data that he is making use of retransmitted data on both up and down.

Yeah when looking at my G.INP DS re-transmit tx/min it looks worse than AlecR's yet his US is having to retransmit more often  :(

Title: Re: G.INP on ECI cabs
Post by: burakkucat on July 25, 2015, 01:21:04 AM
Ah, yes, I see.

So that is further confirmation that AlecR's circuit is not in the best health for the US direction.
Title: Re: G.INP on ECI cabs
Post by: GigabitEthernet on July 25, 2015, 09:40:54 AM
Did I hear my name! :P

The benefit of G.INP for me has to been so significantly reduce my ping times. I'm down to 8ms pings from 30ms pings previously (to the BBC).

FECs are still pretty high on the downstream but on the downstream they are pretty low and I'm getting absolutely no CRCs or ES on the downstream, nor the upstream.
Title: Re: G.INP on ECI cabs
Post by: burakkucat on July 25, 2015, 03:51:40 PM
In the light of what you have reported, we can conclude that "G.Inp just works".  :D
Title: Re: G.INP on ECI cabs
Post by: NewtronStar on July 25, 2015, 09:55:04 PM
In the light of what you have reported, we can conclude that "G.Inp just works".  :D

Of course it's works for him B*CAT the Mk2 is running on both downstream and upstream ;)
it would be my preference to have the upstream G.INP'd on my line as all i see is more US errored seconds on MDWS than DS errored seconds.

kind of knew once the US G.INP was removed the users focus would go straight to the errored seconds on upstream but the MDWS DLM calculator (traffic lights) helps with those anxieties to keep things in perspective  ;D
Title: Re: G.INP on ECI cabs
Post by: Terranova667 on August 11, 2015, 03:53:10 PM
I know it's only been 11 days into August but are there any signs yet of the ECI G.INP roll out ?  that said i don't even know if the roll out for Huawei has been completed yet . 
Title: Re: G.INP on ECI cabs
Post by: Dray on August 11, 2015, 04:08:07 PM
http://forum.kitz.co.uk/index.php/topic,15921.msg296413.html#msg296413
Title: Re: G.INP on ECI cabs
Post by: NewtronStar on August 11, 2015, 07:18:21 PM
Yeap I guess the Plusnet Forum users also need to be updated  ;)
Title: Re: G.INP on ECI cabs
Post by: kitz on August 11, 2015, 10:24:04 PM
Yep...  g.inp has nothing to do with vectoring and crosstalk either.  ::)


Retransmission does not work for all types of noise.. It is NOT noise cancellation and therefore has absolutely no effect on SNRm to be able to give an increase in sync speed.  Retransmission works well for REIN type noise... ie short bursts...  and its all about data recovery of lost packets caused by noise bursts.

Traditionally lines suffering from say REIN type noise would have Interleaving & Error Correction applied using RS encoding which carries an additional overhead. 

Where G.INP can give some sync speed back is if you suffer from REIN type noise and previously had RS Error Correction applied.   By using G.INP rather than RS encoding then you can take away the redundant overheads.   Note: G.INP can only give back what RS encoding may have taken away. It most certainly does not magically give back any sync speed lost through cross-talk.   :no:

Vectoring and g.inp work well together.    Vectoring reducing ingressed line noise and Retransmission working to recover any data packets which may have been lost from environmental type noise.
Title: Re: G.INP on ECI cabs
Post by: GigabitEthernet on August 11, 2015, 10:47:47 PM
Kitz,

In my case I lost a few megabits from crosstalk and when G.INP was enabled this sync speed returned.

I'm now terribly confused :(
Title: Re: G.INP on ECI cabs
Post by: NewtronStar on August 11, 2015, 11:30:41 PM
In my case I lost a few megabits from crosstalk and when G.INP was enabled this sync speed returned.

I'm now terribly confused :(

That's because your line was using interleaving and when G.INP was enabled on the 21st of july the sync increased due to the way G.INP works and nothing to do with crosstalk.

if you looked at your MDWS that's confusion for ya, only messing but i have never seen line stats change so much in 10 days  :) apart from Starman's
Title: Re: G.INP on ECI cabs
Post by: GigabitEthernet on August 11, 2015, 11:42:19 PM
Ah in that case I must have no crosstalk! >:D

With only 40 or so other lines on the cabinet perhaps that isn't surprising.
Title: Re: G.INP on ECI cabs
Post by: kitz on August 12, 2015, 12:11:11 AM
Kitz,
In my case I lost a few megabits from crosstalk and when G.INP was enabled this sync speed returned.
I'm now terribly confused :(

I havent had a look at your stats, but its impossible for g.inp to recover crosstalk sync.   As mentioned above crosstalk is a constant which affects your SNR so the noise is there at sync time.   Retransmission is a method of recovering data in the event of noise bursts.  They work at different levels. 

As NS says the increase will be because Interleaving - or more correctly RS encoding - was turned off when G.INP was applied.  G.INP can only recover any sync speed lost from RS overheads.

Think of it this way: Crosstalk is a constant and you only see your SNRm change with the disturbers line is either switched on or off.    REIN and other environmental type noises cause spikes in the SNRm. 
You should already be familiar with the fact that when SNRm spikes occur then data packets can be lost, which in turn trigger errors such as CRC/FEC/ErrSec/LEFTRS etc. 
In old money it was the job of ReedSoloman redundancy to attempt to recover from FEC. The downside it carried a heavy overhead which subtracted from your available sync speed.
These days the retransmission process only kicks in only when it detects a lost packet and needs to recover it.   But the good thing about g.inp is that it works on the fly without permanent overheads so if the line isnt erroring then it doesnt need any overheads... and hence why it can give back speeds lost through Interleaving and ErrorCorrection.

Hope that helps make things a bit clearer :)

 
Title: Re: G.INP on ECI cabs
Post by: kitz on August 12, 2015, 12:18:45 AM
Ah in that case I must have no crosstalk! >:D

With only 40 or so other lines on the cabinet perhaps that isn't surprising.

I bet there is some... its just that you seldom notice it because it doesn't cause the traditional type of noise spikes from SNRm line monitoring.
But below I will attatch a classic sign of a cross-talker.    Here's one of mine rebooting their router.   Note how its an upwards spike.   Its very easy to see on my line because my SNRm is normally rock steady.   If you also have environment noise and your SNRm is spiking anyhow,  its much harder to spot.
Title: Re: G.INP on ECI cabs
Post by: Dray on August 12, 2015, 12:19:35 AM
The question is how does crosstalk, which is noise, not cause packet loss but REIN, which is noise, does cause packet loss?
Title: Re: G.INP on ECI cabs
Post by: Weaver on August 12, 2015, 12:27:05 AM
The question is how does crosstalk, which is noise, not cause packet loss but REIN, which is noise, does cause packet loss?

I don't understand. Both will cause packet loss surely if sufficiently bad that its uncorrectable?
Title: Re: G.INP on ECI cabs
Post by: kitz on August 12, 2015, 12:43:02 AM
The question is how does crosstalk, which is noise, not cause packet loss but REIN, which is noise, does cause packet loss?

Because crosstalk its a constant noise. Its there at sync time, so during the sync process & analysis its already affecting the SNR so your line rate is set based on the current SNRm and in effect crosstalk noise already allowed for.   Its constant nature means that it doesn't affect your SNRm until the x-talk disturber switches their modem off - or back on.   


REIN/SHINE/PEIN  are all types of noise bursts of various lengths which can cause the SNRm to vary.   A REIN type noise burst causes the downwards spike in SNRm.  When there is insufficient SNRm for the data signal to be heard properly at the other end, the data packet can become corrupt or lost which is what triggers an Error. 

Its spikey nature of low SNRm that causes packet loss.  Anything constant & your modem will factor it in your sync.

 
Title: Re: G.INP on ECI cabs
Post by: GigabitEthernet on August 12, 2015, 12:49:29 AM
Kitz,

I recall seeing somebody saying that after a power cut their sync speed hugely reduced temporarily when the noise was significantly reduced.

Would vectoring give the same sync speed as this situation or would it still be worse?
Title: Re: G.INP on ECI cabs
Post by: kitz on August 12, 2015, 01:04:01 AM
Both will cause packet loss surely if sufficiently bad that its uncorrectable?

Yep.   The time when it can happen with crosstalk is if you sync up and your disturber isnt online.  The following is an example when it may occur: .

Your neighbour goes away on holiday and turns their router off.. and your SNRm goes up to 9dB
Later the same day you do a resync of your modem and it will automatically sync up at 6dB SNRm at 'x' Mbps and is quite happy at 'x'Mbps and doing its normal 1dB varience of between 5dB - 6dB without many errors

A week later your neighbour comes home and turns their modem on.
Immediately your SNRm goes down to 3dB..  and stays at 3dB, but 3dB isnt always enough for an error free line, so errors will start racking up, and if the line then does its daily 1dB variance the line is now  down to 2dB..  and errors will really start going through the roof.


Note: I used an example of 3dB for the disturber but it can be any amount from a fraction to more.  However it will almost always be the same amount from the same disturber.  Some of mine are fractions of a dB, a couple of mine are around 1dB, and I have a few at around 1.5dB.   How much they disturb your line depends upon the proximity of their line to yours, how strong their signal strength is and any PCB or PSD masks in use.
Title: Re: G.INP on ECI cabs
Post by: kitz on August 12, 2015, 01:13:12 AM
Kitz,
I recall seeing somebody saying that after a power cut their sync speed hugely reduced temporarily when the noise was significantly reduced.

Would vectoring give the same sync speed as this situation or would it still be worse?

Ummm.. that doesnt make sense, sync speed doesnt reduce when noise if reduced.    Sync speed goes up when noise is reduced.

If thats a typo..  and you mean what usually happens after a power cut....  if you sync first then you normally get a better speed.   When others start to come back online, then your SNRm starts going down.

In that case:-

Vectoring would be using noise cancellation to mitigate the loss of sync speed.  When neighbours power off or on, you are less likely to notice any difference between your speed variance.
Title: Re: G.INP on ECI cabs
Post by: GigabitEthernet on August 12, 2015, 01:15:41 AM
Sorry yes that was a typo :)

I'm sorry but I don't quite understand your second paragraph. The sync speed would be increased because there was less noise in the environment.

Would vectoring simulate the same conditions as other lines would no longer be interfering with yours?
Title: Re: G.INP on ECI cabs
Post by: kitz on August 12, 2015, 01:28:29 AM
Quote
I'm sorry but I don't quite understand your second paragraph. The sync speed would be increased because there was less noise in the environment.

Yes.  If you are first to sync up then your sync speed would be increased because less noise.  However when those other users start coming online, your 6dB of SNRm will be no more, each time a disturber comes back on, they will gradually eat away at your SNRm

Quote
Would vectoring simulate the same conditions as other lines would no longer be interfering with yours?

I dont know how efficient vectoring is.  Its a noise cancellation technique to reduce crosstalk.   I should imagine the results may vary depending on how much noise the neighbouring line puts on to yours.   They dont all put the same amount of noise on.    Your next door neighbour may not be causing you any crosstalk, but the one across the road and 5 houses down may be causing 2dB.   I honestly don't know, but I dont think it's 100% efficient, just that it makes great improvements. 
Title: Re: G.INP on ECI cabs
Post by: Mark07 on August 12, 2015, 04:10:06 PM
The OR engineer I had out yesterday said they were enabling all newly installed cabs with vectoring... anyone know if this is true?
Title: Re: G.INP on ECI cabs
Post by: GigabitEthernet on August 12, 2015, 04:11:39 PM
I don't think that's true.
Title: Re: G.INP on ECI cabs
Post by: Mark07 on August 12, 2015, 05:00:40 PM
No me neither, but I didn't have the motivation to question it further
Title: Re: G.INP on ECI cabs
Post by: kitz on August 12, 2015, 06:29:14 PM
The OR engineer I had out yesterday said they were enabling all newly installed cabs with vectoring... anyone know if this is true?

Hmmmm...  Equipping / capable perhaps.  Especially if by 'new' he's thinking the BDUK Huaweis.   Enabling is a different matter.