Kitz Forum

Broadband Related => Broadband Technology => Topic started by: Chrysalis on March 17, 2015, 06:02:27 PM

Title: G.INP and ECI
Post by: Chrysalis on March 17, 2015, 06:02:27 PM
Looking on MDWS I see only hauwei g.inp lines, I hope BT are not improving things only for hauwei.

anyone know of any ECI users on G.INP?
Title: Re: G.INP and ECI
Post by: les-70 on March 17, 2015, 07:17:03 PM
 Nope  -- I recall ISPreview commenting that implementation on ECI would definitely be delayed and was uncertain.  I hope it does not prove to be the same for vector.
Title: Re: G.INP and ECI
Post by: Geekofbroadband on March 19, 2015, 01:26:41 AM
By hauwei users do you mean they have to hae a hauwei DSLAM or just the hauwei modem?
Title: Re: G.INP and ECI
Post by: Chrysalis on March 19, 2015, 01:30:38 AM
dslam.
Title: Re: G.INP and ECI
Post by: burakkucat on March 19, 2015, 01:57:13 AM
By hauwei users do you mean they have to hae a hauwei DSLAM or just the hauwei modem?

Explicitly, users whose circuits are connected via Huawei SmartAX MA5616T or Huawei SmartAX MA5603T DSLAMs and not via ECI Hi-FOCuS Mini-Shelf M41 DSLAMs.
Title: Re: G.INP and ECI
Post by: tbailey2 on March 21, 2015, 04:02:31 PM
FYI, as of now, there are 26 G.INP enabled users showing in MDWS - all on Huawei cabs.

I'm on an ECI cab as well   >:(
Title: Re: G.INP and ECI
Post by: Ixel on March 21, 2015, 04:19:26 PM
Does anyone know why BT aren't supporting their ECI DSLAM's? Surely they must be capable of G.INP.
Title: Re: G.INP and ECI
Post by: loonylion on March 21, 2015, 04:42:13 PM
they aren't without expensive upgrades.
Title: Re: G.INP and ECI
Post by: ktz392837 on March 21, 2015, 04:58:31 PM
Does anyone know why BT aren't supporting their ECI DSLAM's? Surely they must be capable of G.INP.
Does anyone have any contacts at BT to try to get answers on this?

I waited for years to get fttc after problems connecting the cabinet and now have crosstalk problems.  I am on an ECI cabinet.  I will not be very pleased if after all this time the cabinet isn't suitable for purpose.

Any ideas on cost of upgrading the cabinets?

Thanks
Title: Re: G.INP and ECI
Post by: tbailey2 on March 21, 2015, 05:29:01 PM
I notice on the PN forums in answer to the why not ECI question:

http://community.plus.net/forum/index.php?topic=136287.64 (http://community.plus.net/forum/index.php?topic=136287.64)

Reply #66 (http://community.plus.net/forum/index.php?topic=136287.msg1210904#msg1210904) on 18/03/2015, 19:28 Ľ ECI cabinets have not been left out - it's already been/being rolled out on them.


I believe there may be some doubt about his statements though? He also says it increases latency?
Title: Re: G.INP and ECI
Post by: boost on March 21, 2015, 06:35:24 PM
The plot thickens :D
Title: Re: G.INP and ECI
Post by: Dray on March 21, 2015, 06:37:23 PM
Maybe he means it increases latency on ECI cabs?
Which is why it's not on...
Title: Re: G.INP and ECI
Post by: WWWombat on March 22, 2015, 02:08:43 AM
I believe there may be some doubt about his statements though? He also says it increases latency?

On some of the Huawei's we've seen, latency has indeed been increased (from no intervention at all). By, oh, say, 0.2ms.
Title: Re: G.INP and ECI
Post by: Chrysalis on March 22, 2015, 02:14:09 AM
I notice on the PN forums in answer to the why not ECI question:

http://community.plus.net/forum/index.php?topic=136287.64 (http://community.plus.net/forum/index.php?topic=136287.64)

  • AndyH (http://community.plus.net/forum/index.php?action=profile;u=19806)
  • Posts: 5583
  • (http://community.plus.net/forum/index.php?action=dlattach;attach=50933;type=avatar)
  • (http://community.plus.net/forum/Themes/plusnet-brand-refresh/images/icons/profile_sm.gif) (http://community.plus.net/forum/index.php?action=profile;u=19806)
Reply #66 (http://community.plus.net/forum/index.php?topic=136287.msg1210904#msg1210904) on 18/03/2015, 19:28 Ľ ECI cabinets have not been left out - it's already been/being rolled out on them.


I believe there may be some doubt about his statements though? He also says it increases latency?

I have spoken to an openreach engineer who says he cant find anything on the intranet to justify what andyh is saying, I dont know what reason andyh would have to lie on this tho other than to deflect anger towards openreach/plusnet.  It is entirely posible my guy is wrong, but BS who posted on here about this as well said the same thing as my guy.

My guy basically said the same as black sheep which is if there was changes on the ECI cabinets then staff in the field would be told about it as it reflects in the troubleshooting process for faults.  He did say tho its possible ECI may have been changed only in limited areas (testing) and that would be done without posting on the intranet.

I also asked him to check the page that andyh told me on the plusnet forum and he said there is no such section for engineers to access, suggesting andyh might have exec level access or something.  But he is still digging for me to try and get some answers to the sort of things andyh posted.
Title: Re: G.INP and ECI
Post by: Black Sheep on March 22, 2015, 05:44:04 AM
Let me put folks minds at rest .......... G.INP is scheduled to be completed on all Huwaei Cabs by Q4 end. Then, work will begin on adding G.INP to ECI DSLAMS in Q1 of the new fiscal year. No links, no references ..... you'll just have to take my word for it.  ;)
Title: Re: G.INP and ECI
Post by: tbailey2 on March 22, 2015, 07:04:28 AM
Let me put folks minds at rest .......... G.INP is scheduled to be completed on all Huwaei Cabs by Q4 end. Then, work will begin on adding G.INP to ECI DSLAMS in Q1 of the new fiscal year. No links, no references ..... you'll just have to take my word for it.  ;)

When is Q4 Fiscal End? April 5th (hopefully)??
Title: Re: G.INP and ECI
Post by: roseway on March 22, 2015, 07:44:45 AM
31st March I believe:

http://www.btplc.com/Sharesandperformance/Quarterlyresults/Quarterlyresults.htm
Title: Re: G.INP and ECI
Post by: tbailey2 on March 22, 2015, 07:53:36 AM
31st March I believe:

http://www.btplc.com/Sharesandperformance/Quarterlyresults/Quarterlyresults.htm (http://www.btplc.com/Sharesandperformance/Quarterlyresults/Quarterlyresults.htm)

So that's in just over a weeks time then!  :o

I say that as elsewhere I think it said it would take until May this year to finish the H cabs, not April?
Title: Re: G.INP and ECI
Post by: Ronski on March 22, 2015, 09:15:42 AM
Thanks very much BS, we'll look forward to seeing some ECI cabs turn green on MDWS.
Title: Re: G.INP and ECI
Post by: Ixel on March 22, 2015, 09:25:10 AM
Thanks BS. That's good to know those on ECI aren't being left in the dark ages :). I was about to comment this morning that maybe BT are doing it in an order of first doing Huawei cabinets, then will move on to ECI cabinets, so what you've said confirms my to be posted comment.
Title: Re: G.INP and ECI
Post by: Chrysalis on March 22, 2015, 09:42:44 AM
Let me put folks minds at rest .......... G.INP is scheduled to be completed on all Huwaei Cabs by Q4 end. Then, work will begin on adding G.INP to ECI DSLAMS in Q1 of the new fiscal year. No links, no references ..... you'll just have to take my word for it.  ;)

thanks for the update. no links needed.

I wonder if andyh will keep claiming the ECI rollout is already in progress.
Title: Re: G.INP and ECI
Post by: broadstairs on March 22, 2015, 10:15:56 AM
Just on question... does Fiscal year mean 1st April to 31st March or is it the same as the calendar year in this case?

Stuart
Title: Re: G.INP and ECI
Post by: Chrysalis on March 22, 2015, 10:22:24 AM
usually it starts april 1st.

but bear in mind Q1 goes all the way to end of june and he only said it be starting then.
Title: Re: G.INP and ECI
Post by: broadstairs on March 22, 2015, 10:39:34 AM
usually it starts april 1st.

but bear in mind Q1 goes all the way to end of june and he only said it be starting then.

That's what I hoped but Fiscal year can be anything a company wants, it does not have to align with either Tax year or calendar year.

Stuart
Title: Re: G.INP and ECI
Post by: roseway on March 22, 2015, 11:25:41 AM
The link I posted above indicates that the BT group uses April 1st as the start of the fiscal year.
Title: Re: G.INP and ECI
Post by: kitz on March 22, 2015, 11:32:43 AM
Thanks for that BS :)
Title: Re: G.INP and ECI
Post by: tbailey2 on March 22, 2015, 11:46:04 AM
The link I posted above indicates that the BT group uses April 1st as the start of the fiscal year.

"G.INP is scheduled to be completed on all Huwaei Cabs by Q4 end"

So that's confirmation that they will be starting on the ECIs any when from 10 day's time onwards ....
Title: Re: G.INP and ECI
Post by: kitz on March 22, 2015, 11:48:07 AM
I also asked him to check the page that andyh told me on the plusnet forum and he said there is no such section for engineers to access, suggesting andyh might have exec level access or something.  But he is still digging for me to try and get some answers to the sort of things andyh posted.

Engineers dont have access to CFPCG.  Thats for the CPs and SPs and even then only certain people in that company will have access.  afaik even the likes of PN reps dont get access... although there will be a few higher up that do.  Perhaps someone like Tomo when they were doing certain trials such as FTTPod or the vectoring trials .

Andy isn't a rep and it wouldnt make sense for someone fairly high up at another SP/CP to be with Plusnet and spend a large amount of time on the PN forums.  My guess is that he's either stumbled on a doc perchance or been passed on by someone that he cant name.    Its common sense that if you come across info like that then you dont disclose your true sources.


---
Cant post inline links
https://www.openreach.co.uk/orpg/home/products/industryforums/industryforumlanding.do
https://www.openreach.co.uk/orpg/home/loadbecomenonportalcustomerform.do
Title: Re: G.INP and ECI
Post by: les-70 on March 22, 2015, 12:57:16 PM
  Maybe it will worth using ECI modems, for short intervals if not for longer, in order to get the modem software update that should occur prior to G.INP implementation.  If you don't the ECI may become unusable should G.INP be enabled on your line. Perhaps anyone using an ECI routinely could keep an eye open for that happening.
Title: Re: G.INP and ECI
Post by: Chrysalis on March 22, 2015, 01:14:38 PM
I think BS has cheered up all people on ECI dslams now :) as at least we now know its coming and we not been abandoned.
Title: Re: G.INP and ECI
Post by: Ixel on March 22, 2015, 01:47:01 PM
  Maybe it will worth using ECI modems, for short intervals if not for longer, in order to get the modem software update that should occur prior to G.INP implementation.  If you don't the ECI may become unusable should G.INP be enabled on your line. Perhaps anyone using an ECI routinely could keep an eye open for that happening.

My ECI /r already reports ReTx stuff via the dsl cpe thingy on telnet, so my guess is mine has already got the firmware upgraded to support G.INP (once the ECI cabinet also offers it) - although I'm not currently using it.
Title: Re: G.INP and ECI
Post by: Ronski on March 22, 2015, 02:07:25 PM
I think BS has cheered up all people on ECI dslams now :) as at least we now know its coming and we not been abandoned.

And we can hope this also means that vectoring is heading our way to.
Title: Re: G.INP and ECI
Post by: boost on March 22, 2015, 02:35:26 PM
  Maybe it will worth using ECI modems, for short intervals

Beginning to wonder if this is why I got slammed with INP from nowhere?

G.inp got enabled, 70 odd modems retrained but not all of us had compatible modems? Could the crosstalk from that make DLM apply emergency style interleaving? :)
Title: Re: G.INP and ECI
Post by: Black Sheep on March 22, 2015, 04:47:53 PM
I think BS has cheered up all people on ECI dslams now :) as at least we now know its coming and we not been abandoned.

And we can hope this also means that vectoring is heading our way to.

It sure does. This will not be an overnight thing, and as always patience is a virtue. But, it will start to be introduced to the larger (MA5603) Huawei DSLAMs initially, then to the smaller (MA5616) Huawei DSLAMs at a later stage. I'm sure ECI will follow at some point but can't comment further on that.

A line can be in 3 different states on a vectored DSLAM depending on the customers CPE:

Vector (Full) = the modem is fully compatible with vectoring and on a DSLAM where vectoring is running it will synch in vectored mode and get a speed result based on that.
Vector (Friendly) = the modem is not fully compatible with vectoring, but can provide some information about cross talk to the DSLAM, this means the vector engine gets results from this which it can use to improve performance for those that are compatible, but this modem itís self will get a standard VDSL speed.
Vector (off) = this is also known as not vector friendly, the modem is not able to support vectoring at all and provides no useful information to the DSLAM about cross talk, and it only gets standard VDSL speed.

Exciting and interesting times lie ahead, methinks ?? I hope it delivers great results, and that the 'Glass half-empty' brigade give it a chance to be implemented before it gets slated ??  :)
Title: Re: G.INP and ECI
Post by: boost on March 22, 2015, 04:56:48 PM
You must have the patience of a saint!  Putting up with us 'orrible lot :D

Thanks for the top info! :)
Title: Re: G.INP and ECI
Post by: Black Sheep on March 22, 2015, 05:24:28 PM
Not really ....... you should see my collection of Voodoo dolls !!  ;) ;D ;D
Title: Re: G.INP and ECI
Post by: renluop on March 22, 2015, 06:51:02 PM
Not really ....... you should see my collection of Voodoo dolls !!  ;) ;D ;D
Sorry! I can't imagine you as a pin up boy! Half a mo; should I have written pinned up :P ;)
Title: Re: G.INP and ECI
Post by: Black Sheep on March 22, 2015, 07:26:12 PM
For 'Pin-up boy' ..... see the G.IMP thread.  ;) ;D
Title: Re: G.INP and ECI
Post by: Black Sheep on March 22, 2015, 07:37:57 PM
Well I never ........... just having a dig around our zillion internal systems and found a site that mentions actual turning on of vectoring.
It's a 'read only' site and won't allow searches. However, it would appear from the limited amount I've seen that vectoring takes approx. 15mins DSLAM downtime to install, and is scheduled to take place anytime between 0100-0600 in the small hours. I'm guessing it could be a robotic task ???
Title: Re: G.INP and ECI
Post by: danivtec on March 22, 2015, 09:42:41 PM
Any indication on when it's due to roll out yet?
Title: Re: G.INP and ECI
Post by: Black Sheep on March 22, 2015, 10:17:53 PM
As we speak, danivtec.  :)
Title: Re: G.INP and ECI
Post by: Ronski on March 22, 2015, 10:25:39 PM
Apart from hopefully an increase in speed is there anyway to tell if vectoring is enabled on a line?
Title: Re: G.INP and ECI
Post by: kitz on March 23, 2015, 12:39:43 AM
Theres a few examples of stats from Eircom vectored lines here (http://www.boards.ie/vbulletin/showthread.php?s=604c73e466a46da3ed3289f507b04fcc&t=2057138390&page=17).    I cant see anything obvious other than the increase in attainable speeds.

That said most arent posting full stats, so there may be some indication elsewhere.
Title: Re: G.INP and ECI
Post by: Ixel on March 23, 2015, 09:25:22 AM
Other than a noticeable change in attainable rate and SNR margin, I don't believe modems typically display the vectoring state.

However, the ASUS (when using TC Console) shows the vectoring state with 'wan adsl diag', and some reasonably good news is that it's looking likely that when G.INP is enabled on a circuit then it will work fine at full sync rate in comparison to the HG612 or ECI /* modems (as G.INP is most likely masking a compatibility issue with a good number of fastpath VDSL2 connections). Hoping ASUS will fix the actual problem in the end however, without me relying on G.INP to save the day.
Title: Re: G.INP and ECI
Post by: ejs on March 23, 2015, 07:18:50 PM
The lantiq dsl_cpe_control vectoring related commands are:

dsmcg DSM_ConfigGet
dsmcs DSM_ConfigSet
dsmsg DSM_StatusGet
dsmstatg DSM_STATisticsGet
dsmmcg DSM_MacConfigGet
dsmmcs DSM_MacConfigSet
Title: Re: G.INP and ECI
Post by: WWWombat on March 24, 2015, 03:51:38 PM
I suspect that the easiest indication that we will get is from the changes to SNRM (and presumably SNRM per band), actual sync speed, and attainable sync speed - which should improve in a variety of ways while the attenuation (and attenuation per band) stays the same.

However, if UPBO stays in place, we might find that some of the increase in SNRM is used to offset a decrease in the transmit power instead. But some of the studies on vectoring suggest that UPBO can be turned off with vectoring - so we might see power increases too.

I wonder if it is worth creating some extra graphs to help document this. I'm thinking of a scatter graph, that plots the attenuation along the X axis, and the attainable speed along the Y-axis. Each point plotted on the scatter would represent the pair of (attenuation, attainable) at one instant in time.

With one user, the accumulated points plotted would show the variation with crosstalk, followed, eventually by a jump as vectoring is introduced - and then variation after this point. However, all points would be on the same vertical line.

If the colour of the points was gradually adjusted over time (from light red to dark red, say), you'd get some idea of how the various points relate to time.

With multiple users results plotted onto one graph, you'd probably get a whole 2D space giving a clue as to the gains possible for vectoring over a variety of attenuations. Perhaps one day we could do the same with actual distance instead of attenuation.
Title: Re: G.INP and ECI
Post by: kitz on March 24, 2015, 10:51:14 PM
Quote
But some of the studies on vectoring suggest that UPBO can be turned off with vectoring - so we might see power increases too.

Ive also seen mention of this.  However my initial thoughts are that BT are normally overly cautious, so whether they would or not is a different matter. ::)
Thinking about it, the lines that are most likely to gain the most from turning off UPBO are short lines which can generally exceed 20Mb anyhow.   It may be of some benefit to longer lines but what about PSD masks which would still need to remain in place? :hmm:
Title: Re: G.INP and ECI
Post by: WWWombat on March 26, 2015, 01:30:24 AM
PSD masks upstream are largely on/off, aren't they? I don't think it varies to allow for ADSL subscribers - certainly it surprises me when I see my (short) D-side line bit-loads US2 to higher levels than US1, but then has US0 has bit-loaded to the same degree as US2. I'd have thought that minimising US0 usage, when possible, would be useful.
Title: Re: G.INP and ECI
Post by: kitz on March 26, 2015, 01:52:55 AM
Sorry I wasnt very specific because I when I mentioned long lines... I was thinking about U0 & D1, which is where most of their bit loading occurs.. and those were the PSD masks I was thinking off.. because those tones are shared with adsl/adsl2+.

Im on a shortish line (300m) and like you it PCB applied quite heavily in U1.  If vectoring is as good as they say, then there shouldnt be any need for that as those tones are purely VDSL/VDSL2 lines.
Title: Re: G.INP and ECI
Post by: Bowdon on March 26, 2015, 10:46:46 AM
I keep reading that Sky already deploy G.INP. How do they do this?

Like I'm on an ECI cabinet, so if I went to Sky for my fibre, how would they deliver G.INP to me?

I don't understand how they are using it, and using the BT network, but BT themselves haven't used it. How does that work?
Title: Re: G.INP and ECI
Post by: boost on March 26, 2015, 11:04:42 AM
I keep reading that Sky already deploy G.INP. How do they do this?

Like I'm on an ECI cabinet, so if I went to Sky for my fibre, how would they deliver G.INP to me?

I don't understand how they are using it, and using the BT network, but BT themselves haven't used it. How does that work?

I think that might be in relation to their ADSL LLU offerings?
Title: Re: G.INP and ECI
Post by: Chrysalis on March 26, 2015, 12:27:42 PM
they been using it on their LLU adsl for a while.
Title: Re: G.INP and ECI
Post by: Bowdon on March 26, 2015, 01:09:16 PM
Ahhh.. I didnt realise it was for adsl.  :-[
Title: Re: G.INP and ECI
Post by: Black Sheep on March 26, 2015, 08:44:11 PM
I think BS has cheered up all people on ECI dslams now :) as at least we now know its coming and we not been abandoned.

And we can hope this also means that vectoring is heading our way to.

I can confirm vectoring trials on ECI are happening, and I've even seen a photo (boring as it is) of the ECI vectoring engine shelf. For commercially sensitive purposes, I cannot post anything more. But, it's another step in the right direction for the ECI customers IMHO.
BTW, I've no idea of projected timescales regarding final trials to implementation ..... sorry.
Title: Re: G.INP and ECI
Post by: Black Sheep on March 26, 2015, 08:50:05 PM
Quote
But some of the studies on vectoring suggest that UPBO can be turned off with vectoring - so we might see power increases too.

Ive also seen mention of this.  However my initial thoughts are that BT are normally overly cautious, so whether they would or not is a different matter. ::)
Thinking about it, the lines that are most likely to gain the most from turning off UPBO are short lines which can generally exceed 20Mb anyhow.   It may be of some benefit to longer lines but what about PSD masks which would still need to remain in place? :hmm:

UPBO may not be required in a fully vectored system.  However, if SLU (Sub-loop unbundling) or non-vectored modems present, UPBO will still be required.
Title: Re: G.INP and ECI
Post by: Mike Turner on March 27, 2015, 12:14:25 PM
I am not an expert in this area, and may have completely misunderstood, but I thought that I was on an ECI cabinet, and my Fritzbox 7490 makes me think that I have G.INP enabled.

Have a look at the following screenshots:-

By the way, there is something that might be relevant - I live in Martlesham Heath.
Title: Re: G.INP and ECI
Post by: WWWombat on March 27, 2015, 12:25:45 PM
With an INP value of 44, it certainly seem like you have G.INP running.

The mention of G.INP itself might be a red herring - in other modems, a setting of "on" merely indicates that the modem is willing to allow G.INP, rather than indicating that it is turned on. However, that screen layout on the fritz might well indicate that it is actually turned on.

You are obviously an unwitting guinea pig, living there...
Title: Re: G.INP and ECI
Post by: Mike Turner on March 27, 2015, 12:27:31 PM
Unwitting - perhaps. But unwilling - definitely not.

They can even test vectoring on my line, if they want.
Title: Re: G.INP and ECI
Post by: AArdvark on March 27, 2015, 12:30:55 PM
Quote
I live in Martlesham Heath

All you need to know.

Bet you get vectoring 1st as it slips out  ;D

No doubt just a test that happens to be useful to the BT people that live near.  ::)  ;D
Title: Re: G.INP and ECI
Post by: boost on March 27, 2015, 12:34:54 PM
Nice! I've heard there is a world outside the M4 corridor.
What's in Martlesham Heath? :P
Title: Re: G.INP and ECI
Post by: AArdvark on March 27, 2015, 12:37:34 PM
BT's global skunkworks other wise known as Adastral Park.

Jargon decypher:
The designation "skunk works" or "skunkworks*" is widely used in business, engineering, and technical fields to describe a group within an organization given a high degree of autonomy and unhampered by bureaucracy, tasked with working on advanced or secret projects.
[All the 'Good' stuff  ;D]

*Origin Story: http://www.lockheedmartin.co.uk/us/aeronautics/skunkworks/origin.html (http://www.lockheedmartin.co.uk/us/aeronautics/skunkworks/origin.html)
Title: Re: G.INP and ECI
Post by: Mark07 on March 27, 2015, 12:41:33 PM
I'm using a Huawei on an ECI cab, and my stats say 5 for INP....  ???

Also I  guess when the ECI cabs are enabled I'll be ready to go, I have the latest (v30) of the modem firmware which should compatible with an ECI cab running INP (and vectoring eventually)  right??   ;D
Title: Re: G.INP and ECI
Post by: Ixel on March 27, 2015, 01:30:38 PM
With an INP value of 44, it certainly seem like you have G.INP running.

The mention of G.INP itself might be a red herring - in other modems, a setting of "on" merely indicates that the modem is willing to allow G.INP, rather than indicating that it is turned on. However, that screen layout on the fritz might well indicate that it is actually turned on.

You are obviously an unwitting guinea pig, living there...

I can confirm that as having used a FB 7490 on my connection, if it says on that it means it's definitely on (not that it's just supported). On my own connection it has said off when I used it.
Title: Re: G.INP and ECI
Post by: AArdvark on March 27, 2015, 02:19:55 PM
Anyone willing to call this the 1st ECI G.INP'd ?
Title: Re: G.INP and ECI
Post by: WWWombat on March 27, 2015, 02:58:00 PM
@Mike Turner

Can you manage to post detailed line statistics from a telnet session into the modem? It'll be useful to compare with the existing ones on Huawei DSLAMs...
Title: Re: G.INP and ECI
Post by: Mike Turner on March 27, 2015, 03:01:37 PM
I'm afraid that I don't know the telnet commands for the FB 7490. I don't believe that it has the Broadcom chip.

If anyone can tell me the commands, I am quite willing to post the results.
Title: Re: G.INP and ECI
Post by: Ixel on March 27, 2015, 03:13:31 PM
If I can find the commands I used when I was using the the FB 7490 then I'll post them, unfortunately I didn't keep notes as there wasn't any real interest in my FB 7490 thread a while ago. An example of the output I had a while ago is at http://pastebin.com/raw.php?i=bSuFD3x2 if anyone's curious. It's quite detailed.

EDIT: In telnet you run the following... dsl_monitor --supportdata

You must enable telnet via the telephone (e.g. DECT or connect one to the phone socket on the back). Google for instructions on that one.
Title: Re: G.INP and ECI
Post by: Mike Turner on March 27, 2015, 03:28:42 PM
Hows this:-

Title: Re: G.INP and ECI
Post by: NewtronStar on March 27, 2015, 08:33:32 PM
Hows this:-

I had a look and there is loads of stuff in this mdem txt dunp i am not seeing anything that suggests G.INP is enabled
Title: Re: G.INP and ECI
Post by: Ixel on March 27, 2015, 08:44:33 PM
Hows this:-

I had a look and there is loads of stuff in this mdem txt dunp i am not seeing anything that suggests G.INP is enabled

Then I recommend visiting Specsavers or an alternative optician ;).

Code: [Select]
DS Delay         : 0
DS INP           : 44.0

...

DS RTX active                         : 1
DS RTX used                           : RTX in use

Although the statistics don't appear to be meaningful.

Mine said this:
Code: [Select]
DS Delay         : 11
DS INP           : 7.0

...

DS RTX active                         : 0
DS RTX used                           : RTX_USED unknown
Title: Re: G.INP and ECI
Post by: NewtronStar on March 27, 2015, 09:42:16 PM
Then I recommend visiting Specsavers or an alternative optician ;).

I did wonder why no members were putting there conculsion into mike turners stats so i decided to roll the ball to initiate a responce and since you have responded would you be able to walk us though was your seeing so far ?
Title: Re: G.INP and ECI
Post by: Ixel on March 27, 2015, 11:00:39 PM
Then I recommend visiting Specsavers or an alternative optician ;).

I did wonder why no members were putting there conculsion into mike turners stats so i decided to roll the ball to initiate a responce and since you have responded would you be able to walk us though was your seeing so far ?

I'm confused by your question, I thought I quoted the comparisons above - pointing out where it's indicating retransmission/G.INP is active.

However, I do find one thing puzzling. That is the upstream shows no G.INP.
Title: Re: G.INP and ECI
Post by: NewtronStar on March 27, 2015, 11:50:06 PM
I'm confused by your question, I thought I quoted the comparisons above - pointing out where it's indicating retransmission/G.INP is active.

Honestly the extra data that's showing with G.INP enable lines/modems is confusing i just thought you could help me and maybe others understand or interpret this data  :)
Title: Re: G.INP and ECI
Post by: tbailey2 on March 28, 2015, 07:51:30 AM
I'm confused by your question, I thought I quoted the comparisons above - pointing out where it's indicating retransmission/G.INP is active.
\

Honestly the extra data that's showing with G.INP enable lines/modems is confusing i just thought you could help me and maybe others understand or interpret this data  :)

Not quite sure what the problem is but using even more words on the data Ixel posted:

DS RTX means Downstream Retransmission  - and the latter is G.INP technology - and 1 means it's active and In Use as it says

DS RTX active                         : 1
DS RTX used                           : RTX in use

At least that's how my simple mind sees it. The detail that BE1 has posted elsewhere though I have no idea  ???

FWIW there are now some 40+ users Live on MDWS with G.INP applied, all on Huawei cabs so far.

Edit: one more now with adslmax in the fold....

Every one of these so far has values of INP of 40+ applied on both U/S and D/S - no one has it only on D/S so far....

Attached is a list of them all for reference if you don't use MDWS.

Title: Re: G.INP and ECI
Post by: Ixel on March 28, 2015, 09:47:58 AM
I wonder if ECI's going to have it on downstream only for some reason, or whether it's something on the Fritz!Box 7490 that's controlling the upstream side of the G.INP and saying 'no' somehow? I know the FB 7490 has a habit of dynamically choosing whether bitswap's needed or not as when it's first synced it will say bitswap is off for both DS and US, and then may later on say it's on for either DS or US or even both.
Title: Re: G.INP and ECI
Post by: AArdvark on March 28, 2015, 10:53:41 AM
From my understanding of the G.998.4 standard (G.INP), it is not meant to be applied symmetrically by default.

That is to say the analysis of the line that instigates the switching on of G.INP can decide that only DS or even US needs to be enabled.

Looking through the details of various vendors implementations of G.INP on their kit it is seen that updates have been made to allow DS/US to be independently enabled.
(Possibly they thought that DS/US should be enabled at the same time *incorrectly*)

This means that the Fritzbox may be enabling only DS because that is what DLM has decided after the line analysis.

People with more knowledge please correct me if I am wrong. I want to understand how it all works *correctly*.
Title: Re: G.INP and ECI
Post by: ejs on March 28, 2015, 11:59:39 AM
BT SIN 498 lists support for G.INP on the upstream as a non-mandatory feature, it says "should" rather than "shall".
Title: Re: G.INP and ECI
Post by: AArdvark on March 28, 2015, 04:00:23 PM
Thanks ejs.
That shows BT's focus is on the DS.
Be interesting to know vendors that don't support G.INP on the US. ?
So strange it is not mandatory.
Title: Re: G.INP and ECI
Post by: AArdvark on March 28, 2015, 04:02:41 PM
Is there a potential gain to be had not having G.INP on the US ?
Title: Re: G.INP and ECI
Post by: Chrysalis on March 28, 2015, 04:16:11 PM
compute power?
Title: Re: G.INP and ECI
Post by: AArdvark on March 28, 2015, 04:22:44 PM
I expect the kit involved should be able to handle all the compute intensive protocols it is designed to support. If you are having to switch capabilities off the hardware is under-spec'd for the job. i.e. the hardware should be tested to support ALL compute intensive modes at once if it is possible they may be used concurrently.

Update:
Sorry if this sounds like a snipe Chrysalis, not intended. Just re-read it and added this note.
I have a thing about hardware that is specced to 'just about' work. See posts about problem PhilipD is having with the Zyxel 8924 as an example.
http://forum.kitz.co.uk/index.php/topic,15038.msg280171.html#msg280171 (http://forum.kitz.co.uk/index.php/topic,15038.msg280171.html#msg280171)
Title: Re: G.INP and ECI
Post by: WWWombat on March 29, 2015, 04:17:24 AM
The need for lower error rates comes from video streaming - particularly the need for broadcast-like picture quality, with very low breakups. The requirements are probably an order of magnitude more stringent then the needs for datacomms.

With this in mind, it isn't really a surprise that full g.INP support is not needed for upstream.
Title: Re: G.INP and ECI
Post by: AArdvark on March 29, 2015, 01:53:40 PM
Didn't think beyond the UK Domestic & Business BB arena.  :blush:

In Europe & beyond there are combined TV/BB packages that supply over VDSL2. :idea: 
Mea Culpa.
Title: Re: G.INP and ECI
Post by: kitz on March 30, 2015, 12:40:11 AM
Thanks Mike for sharing that info.  It certainly does look like you are the first, so it does at least give some of us hope that it may be on the way for other ECI cabs. :fingers:

Quote
Edit: one more now with adslmax in the fold....

Now that one is interesting.   afaik, theres no reason why it would be applied to his line.
It looks like its given him and 0.8db of SNRm and attainable from 99500 -> 104750

He's also now seeing his first FECs, but not very many... and no CRCs, but a few E/S.   I had wondered why he hadnt said anything but I also note he's had no line status since lunch time.
Title: Re: G.INP and ECI
Post by: Bowdon on April 06, 2015, 11:06:06 PM
Anymore updates on the situation with ECI cabs?

I think someone said the ECI cabs were going to have G.INP implemented from April 2nd.
Title: Re: G.INP and ECI
Post by: Ixel on April 07, 2015, 09:48:10 AM
It's supposed to be between April to the end of June.
Title: Re: G.INP and ECI
Post by: Chrysalis on April 07, 2015, 03:28:13 PM
I dont think anyone has said ECI will be finished this quarter, only that it will "start" this quarter.
Title: Re: G.INP and ECI
Post by: kitz on April 07, 2015, 09:30:48 PM
I cant recall seeing an actual end date either.. just a start date.
But it took them 2.5 months to do all the Huawei's and theres more of them than ECI's 
Title: Re: G.INP and ECI
Post by: Chrysalis on April 07, 2015, 09:38:58 PM
agreed its logical the time will be within the 2.5 months but its possible they may not start till near the end if the quarter. :) perhaps more likely now that some problems have been raised by the isps.
Title: Re: G.INP and ECI
Post by: CarlT on April 09, 2015, 10:30:51 PM
I cant recall seeing an actual end date either.. just a start date.
But it took them 2.5 months to do all the Huawei's and theres more of them than ECI's

Scheduled to have started now, ramping up in May, complete by June.
Title: Re: G.INP and ECI
Post by: Dray on April 09, 2015, 11:52:53 PM
Just a guess but I'd say you don't work for Openreach, so where is this information coming from?
Title: Re: G.INP and ECI
Post by: Mike Turner on July 02, 2015, 08:26:09 AM
I'm not sure if this is bad news for ECI cabinet users or not, but, after a VDSL reconnect this morning, I've lost G.INP on my ECI cabinet here in Martlesham Heath.

If it is of any interest, my basic before and after stats are:-

Attainable down from 62162 to 59221
Attainable up from 16631 to 18768
Actual down from 62162 to 51130
Actual up from 16631 to 18719
Latency down from Fast to 8ms
Latency up from 8ms to 0
INP down from 44 to 3
INP up from 2 to 0
G.INP down from On to Off
G.INP up from Off to Off
SNR down from 6 to 6
SNR up from 6 to 6
Bitswap down from On to On
Bitswap up from Off to On

It's all beyond me, but I can understand why losing downstream G.INP would lose me some downstream speed, but I don't know enough to understand why I should gain some upstream speed.
Title: Re: G.INP and ECI
Post by: Dray on July 02, 2015, 08:33:05 AM
Shame you're not using MDWS, but it looks like G.INP mk2 has been applied.
Title: Re: G.INP and ECI
Post by: Mike Turner on July 02, 2015, 08:36:43 AM
Surely, if that was the case, G.INP down wouldn't have gone from On to Off.
Title: Re: G.INP and ECI
Post by: WWWombat on July 02, 2015, 02:28:41 PM
It does indeed look like G.INP has been removed entirely - though it looks like it only existed downstream anyway. We'd expect that, with an ECI cabinet.

In the old configuration, you had G.INP protection downstream (with INP=44, delay=0ms), and standard FEC+interleaving protection upstream (with INP=2, delay=8ms). This means you had a round-trip latency delay of 8ms (probably just over), and probably lost around 15% of the upstream bandwidth to the FEC process.

In the new configuration, you now have standard FEC+interleaving protection downstream (INP=3, delay=8ms), and no protection upstream (INP=0, delay=0ms). This means you still have a round-trip delay of 8ms (but it has swapped from being within the upstream path to being within the downstream path). Without FEC on the upstream, you notionally have more bandwidth available to the user data. However, on a lot of lines (at least where capacity is available), the modems choose to add extra FEC protection even when DLM hasn't asked for it; in your case, the spare capacity isn't there, so perhaps the modems haven't bothered to put it in place.
Title: Re: G.INP and ECI
Post by: Mike Turner on July 02, 2015, 02:38:34 PM
Thanks for that clear explanation. My latency doesn't appear to have changed, (about 25 ms before and after), which fits with what you say.