Post by: Bowdon on February 26, 2017, 05:10:19 PM
It looks like the G.INP (I'm assuming thats what he means by retransmission) firmware update as been delayed according to AndyHCZ
Quote
The planned re-introduction of retransmission on ECI estate was due for next month, but I've been informed that this is now not likely to happen. During testing of the updated ECI firmware (which will retrain a line if it becomes 'stuck' due to noise being generated on the line), unrelated issues were found which are now being resolved between ECI and Openreach. This means the likely updated firmware due next month is now going to be held back.
No timescales are given or what the unrelated issues are, but I will update if they are released.
Post by: Dray on February 26, 2017, 05:27:10 PM
Post by: skyeci on February 26, 2017, 05:30:21 PM
point. The last official update originally suggested april 2017 so we will have to see.
Post by: g3uiss on February 26, 2017, 05:36:51 PM
Disappointing if fact
Quote from: AndyHCZ
ECI & Retransmission
[link to this post (http://forums.thinkbroadband.com/fibre/t/4532366-eci-and-retransmission.html)]
The planned re-introduction of retransmission on ECI estate was due for next month, but I've been informed that this is now not likely to happen. During testing of the updated ECI firmware (which will retrain a line if it becomes 'stuck' due to noise being generated on the line), unrelated issues were found which are now being resolved between ECI and Openreach. This means the likely updated firmware due next month is now going to be held back.
No timescales are given or what the unrelated issues are, but I will update if they are released.
[Moderator edited to enclose the quotation within [quote] . . . [/quote] tags, add the link to the original post and provide an attribution to the author.]
Post by: Dray on February 26, 2017, 05:57:14 PM
Post by: ejs on February 26, 2017, 06:05:34 PM
Post by: g3uiss on February 26, 2017, 06:10:51 PM
You can see it on ThinkBroadband near the top of the list of hot topics.
Tomy
Post by: Dray on February 26, 2017, 06:18:59 PM
[Moderator note -- Both threads on this topic have been merged together.]
Post by: g3uiss on February 26, 2017, 06:23:34 PM
Post by: skyeci on February 26, 2017, 06:40:11 PM
Post by: Dray on February 26, 2017, 06:40:37 PM
Post by: skyeci on February 26, 2017, 06:42:10 PM
Exactly. At the moment it's just a rumour
My thoughts exactly. Will keep an eye to see if OR update the briefings on ECI g.inp at some point..
Post by: ejs on February 26, 2017, 07:45:14 PM
Post by: skyeci on February 26, 2017, 07:56:33 PM
Post by: burakkucat on February 26, 2017, 08:31:11 PM
Perhaps the title of this post should have the word "possibly" added - ::)
Hint noted and actioned accordingly! ;)
Post by: Bowdon on February 26, 2017, 08:44:57 PM
Andy seemed to be pretty knowledged up when it came to eci cabinets last time.
Post by: Chrysalis on February 26, 2017, 09:01:45 PM
I am sat here wondering have openreach been sitting on this firmware for several months and only decided to test it now because of their odd schedule where they will only rollout new stuff in spring. It would be very annoying now if this gets delayed an entire year because they will only try it again in spring 2018.
Post by: skyeci on February 26, 2017, 09:15:31 PM
https://www.openreach.co.uk/orpg/home/updates/briefings/super-fastfibreaccessbriefings/sffabriefings.do
Post by: EvilShubunkin on February 26, 2017, 10:27:46 PM
Meanwhile "ayeaye" on mydsl still has his g.inp enabled on his eci cab ::)
Yup and a 4.8dB downstream SNR following a powercut one night and must have been one of the first to resync, although B0 FEC spiking to what seems to me to be a lot but isn't impacting on anything noticeably.
Still, I'm not rebooting that modem if I can help it ;D
So how come my line / cabinet still has G.INP?
Post by: ktz392837 on February 26, 2017, 10:45:58 PM
It would be very annoying now if this gets delayed an entire year because they will only try it again in spring 2018.
My main issue with BT is they seem to be just not giving the problem any urgency. It is a joke it takes so long for them to develop and test changes.
They picked the hardware it does not work they should get a refund from ECI and replace or turn off GINP on *all* cabinets as if it is not needed on ECI cabs it should not be needed on others.
I had a max possible connection of approx 100/30 so originally had 80/20 no problem. It is now 58/15 and apparently this is normal for my line and due to BT continually changing the estimate values downwards due to their dire choice of cabinet not a hope of any relief if these rumours are true.
BT need to add to their disclaimer speed dependent on copper line conditions / line length and whether you are "lucky" enough to have the decent or substandard cabinets.
Assuming 30% of the cabinets are ECI I think it is safe to assume 30% of customers are receiving a substandard service compared to the other 70%
Post by: Bowdon on February 27, 2017, 12:53:41 AM
If its not, then I wonder if they would prioritise ECI cabinets for G.fast as it'll solve the G.INP issue at the same time?
if G.INP is needed then we're screwed for G.fast.. smh
Post by: skyeci on February 27, 2017, 05:42:17 AM
Yup and a 4.8dB downstream SNR following a powercut one night and must have been one of the first to resync, although B0 FEC spiking to what seems to me to be a lot but isn't impacting on anything noticeably.
Still, I'm not rebooting that modem if I can help it ;D
So how come my line / cabinet still has G.INP?
Not sure how,perhaps others on your cab have bt tv as I thought you said you didnt as it was thought to be left on for that. May even just be that yours slipped through the net?.. I wonder if when it gets rolled again should it ever return you may lose it briefly so perhaps it would be an early indicator changes were on the way.. Will be checking your line ;)
Where are you located ?
Post by: EvilShubunkin on February 27, 2017, 07:43:59 AM
Not sure how,perhaps others on your cab have bt tv as I thought you said you didnt as it was thought to be left on for that. May even just be that yours slipped through the net?.. I wonder if when it gets rolled again should it ever return you may lose it briefly so perhaps it would be an early indicator changes were on the way.. Will be checking your line ;)
Where are you located ?
I do have BT TV which was thought to be the reason at one point.
Exchange is Aberdeen Kincorth.
Cabinet we're connected to recently (last 6 months) had a 2nd fibre cabinet installed, also an ECI cabinet. Would be interesting to see if a new line connected to the 2nd fibre cabinet would get G.INP - sounds like it wouldn't. Annoyingly, cabinet around the corner is also getting a 2nd fibre cabinet - just got placed last week - and it looks a lot larger so I assume is a Huawei.
Post by: j0hn on February 27, 2017, 10:20:09 AM
New lines on the 2nd cabinet wouldn't have G.INP. They likely won't on your cabinet either. Your line having G.INP doesn't mean anyone else on the same cabinet does. It's an individual line DLM profile.
The few examples where it remains on ECI cabinets have all had BT TV at the time the rollout was halted. DLM resets seem to remove it permanently. Taking BT TV after the fact makes no difference.
Is G.INP needed when G.fast comes out?Completely irrelevant. Adding a G.Fast pod with G.INP next to an ECI cabinet without it wouldn't help anyone on the ECI cabinet. They are completely independent of each other. It would only help those taking G.Fast. It's best to just forget the fibre cabinet even exists when it comes to G.Fast.
If its not, then I wonder if they would prioritise ECI cabinets for G.fast as it'll solve the G.INP issue at the same time?
if G.INP is needed then we're screwed for G.fast.. smh
G.Fast will likely have some error correction like G.INP. It may be named something different, I have no idea.
Post by: tubaman on February 27, 2017, 10:48:26 AM
...
They picked the hardware it does not work they should get a refund from ECI and replace or turn off GINP on *all* cabinets as if it is not needed on ECI cabs it should not be needed on others.
...
Please don't suggest that - G.INP gains me 6 or 7 Mbps (from 35 up to 41 / 42) on a Huawei cabinet. :no:
BT really need to sort this as the current inequity between the cabinet types is appalling. :(
Post by: Bowdon on February 27, 2017, 12:01:25 PM
Completely irrelevant. Adding a G.Fast pod with G.INP next to an ECI cabinet without it wouldn't help anyone on the ECI cabinet. They are completely independent of each other. It would only help those taking G.Fast. It's best to just forget the fibre cabinet even exists when it comes to G.Fast.
G.Fast will likely have some error correction like G.INP. It may be named something different, I have no idea.
Yes that is why I was asking.
The more technology the Huawei cabinets can support we'll start the see a speed divide between the 2 types of cabinet.
G.fast will be a leveller. It'll bring people left behind in speed back closer together using G.fast. So I'm wondering if G.fast will be prioritised for ECI cabinets. Then they won't need to fiddle around with G.INP much.
Post by: j0hn on February 27, 2017, 01:13:40 PM
It doesn't level anything up though. The majority of customers will keep FTTC. I'll never get G.Fast. I really can't see OpenReach going deeper into the network and using nodes on a large scale.
Post by: Chrysalis on February 27, 2017, 03:43:43 PM
Post by: ktz392837 on February 27, 2017, 07:48:02 PM
Please don't suggest that - G.INP gains me 6 or 7 Mbps (from 35 up to 41 / 42) on a Huawei cabinet. :no:I think everyone knows I am just venting that is why no one replies. At least I know one person has got my point - BT should fix the ECI cabs before bringing even more improvements to the Huawei.
BT really need to sort this as the current inequity between the cabinet types is appalling. :(
Post by: ktz392837 on February 27, 2017, 08:01:12 PM
99% of customers don't know the difference between the 2 cabinet vendors.
Here in my old fogey cave I agree with you but I bet there would be more of an unroar if people knew the ECI cabs that BT used were so much worse and people pay the same for the privilege to use them.
I am going on a road trip soon (i'm not but I promise I will stop venting soon). My car is 15% slower and 15% less fuel efficient due to me being unlucky the manufacturer chose two suppliers for a part but I got the dodgy one. They only use the one that works now but they say the dodgy part is working fine.
Post by: burakkucat on February 27, 2017, 08:05:07 PM
. . . BT should fix the ECI cabs before bringing even more improvements to the Huawei.
It is up to ECI to provide the fix(es) to the systems that they, ECI, have supplied.
I am quite certain that the customer, the BT Group, is applying pressure onto the supplier, ECI, for such remedial action.
Post by: Black Sheep on February 27, 2017, 08:11:41 PM
Post by: broadstairs on February 27, 2017, 08:17:12 PM
It is up to ECI to provide the fix(es) to the systems that they, ECI, have supplied.
I am quite certain that the customer, the BT Group, is applying pressure onto the supplier, ECI, for such remedial action.
Whilst I agree with that to an extent I am convinced that the BT Group are not really putting that much pressure on ECI as probably the vast majority of customers on ECI equipment do not complain. BT have made a huge error in using ECI equipment and because of that they should be creating merry hell with ECI to fix it, but they wont unless either a very significant proportion of users on the ECI estate start to complain or OFCOM and the Government put pressure on them. They have made a fundamental error in not doing proper due diligence prior to using ECI equipment.
If 10% of the customers complain they can put up with that, if it were 80+% things would be different. Lets face it most of Joe Public are not bothered and therefore letting BT off the hook.
Stuart
Post by: skyeci on February 27, 2017, 08:31:34 PM
Post by: NewtronStar on February 27, 2017, 08:46:10 PM
(A) connected to a ECI @ 300 meters to cabinet with a sync of 70 Mbps and running ok with fastpath with no G.INP
(B) Connected to Huawei @ 1000 meters with 36Mbps and using G.INP i'll go with option A anyday
Post by: broadstairs on February 27, 2017, 09:01:03 PM
If you gave me these two options -
(A) connected to a ECI @ 300 meters to cabinet with a sync of 70 Mbps and running ok with fastpath with no G.INP
(B) Connected to Huawei @ 1000 meters with 36Mbps and using G.INP i'll go with option A anyday
But I'm on an ECI around 300 mtrs from cabinet capped at 59995kbps on fastpath and unable to get cap removed. On G.INP I had 70000+kbps on same cabinet, how is that reasonable.
Stuart
Post by: ktz392837 on February 27, 2017, 09:23:39 PM
But I'm on an ECI around 300 mtrs from cabinet capped at 59995kbps on fastpath and unable to get cap removed. On G.INP I had 70000+kbps on same cabinet, how is that reasonable.That is the ever decreasing estimates problem meaning BT never acknowledge a problem (as the estimate changes to your line speed) therefore you are stuck.
Stuart
ISPs should be able to click a button and reset the line to remove banding especially if you have excess db available over the normal 6db.
Put a suitable cap on the number of resets per day across the ISP and perhaps per user per year to stop over usage.
Even if ECI gets GINP as you are capped you probably wouldn't get chance to take advantage as the DLM is so stupid.
Post by: Dray on February 27, 2017, 09:33:50 PM
Post by: ktz392837 on February 27, 2017, 09:49:07 PM
If you gave me these two options -
(A) connected to a ECI @ 300 meters to cabinet with a sync of 70 Mbps and running ok with fastpath with no G.INP
(B) Connected to Huawei @ 1000 meters with 36Mbps and using G.INP i'll go with option A anyday
I suspect 70Mbps connection at 300m on ECI without GINP is a dream for many especially if there are more than a few people on the cab.
Obviously a line that is 700m closer is going to be better. In my opinion a fairer example would be a line 400m away on an ECI running 50-60Mbps or a line running on Huawei with GINP running 60-70Mbps and with 3db 80Mbps.
I would want the Huawei.
BT selected the cabinets they should have the same functionality. I think BT should be forced to say that it is not just line length and copper conditions - speed also depends on what cabinet type - I bet that would focus their minds.
~2 years trialling ECI GINP how long before they should get compensation from ECI and replace the cabs.
I do have symphony for BT in many areas but this is a screw up and they should do more.
Post by: ktz392837 on February 27, 2017, 09:54:30 PM
When you sign up you are given an estimate by the ISP. What was your estimate?For me when I first signed up 80/20 but as years have passed each time I sign up for a new contract they use the current estimate therefore I can't make a complaint or anything. If I wasn't on an ECI cab there would be much less of a problem due to GINP and certainly if 3db was active I would still have a 80/20 connection.
Post by: NewtronStar on February 27, 2017, 10:36:25 PM
I can't get BT Openreach to move my FTTC and PCP cabinet closer to my house and 300 meters would be nice you just have to take it on the chin.
Post by: broadstairs on February 28, 2017, 07:26:06 AM
Come on guys you can't decide what type of cabinet your line is assigned to or how far you are from the cabinet it's just the luck of the draw.
I can't get BT Openreach to move my FTTC and PCP cabinet closer to my house and 300 meters would be nice you just have to take it on the chin.
Yes that's true BUT and its a big BUT BT are using substandard equipment in ECI cabinets, that is the point I think being made here.
If you are on Huawei cabinets then you have a superior service no matter how far you are from the cabinet or how many disturbers you might have. BT have a duty in my view to either fix it or replace the ECI estate with equipment which is not substandard. Now I guess the bean counters want ECI to fix the stuff but it seems likely that their design is so flawed that this is unlikely to be possible at least in the short term. If it cannot be fixed then as it is not fit for purpose ECI shold be made to pay a significant refund to BT which might just allow something else to be done.
Stuart
Post by: PhilipD on February 28, 2017, 08:06:17 AM
I doubt BT are worried about this scenario, for a start no one can prove anything as you can't swap out from an ECI cab to an Huawei to prove what speed you would get. Plus VDSL has many variables nothing is guaranteed.
BT never advertised G.INP or that customers speeds might improve because of it and latency may drop (due to the removal of interleaving), and the vast majority of people have no idea about it. Inequality of services exist all over the place even when people are paying more for that service, for example some people commute to work in quiet air conditioned trains with room to sit down whilst others travel in over-crowed dirty carriages with delays and cancellations the norm.
BT are not going to be worried about trying to fix G.INP on ECI cabs as Long Reach G.FAST is what they are trying to get working now, another system hacked about with to satisfy the accountants which will see those with slow VDSL due to line distance stuck on slow VDSL still. Long range G.FAST is struggling to support vectoring where 96 ports are now required rather than G.FASTs design target of 12-16 ports in a pod near to customer premises, so I suspect there will be similar issues where version 2 kit ends up working better than older kit and BT will not bother to fix that either.
Regards
Phil
Post by: broadstairs on February 28, 2017, 08:10:25 AM
However snow flakes chance in hell comes to mind, no one in any position of power really cares.
Stuart
Post by: lee111s on February 28, 2017, 08:52:26 AM
I suspect 70Mbps connection at 300m on ECI without GINP is a dream for many especially if there are more than a few people on the cab.
Obviously a line that is 700m closer is going to be better. In my opinion a fairer example would be a line 400m away on an ECI running 50-60Mbps or a line running on Huawei with GINP running 60-70Mbps and with 3db 80Mbps.
I would want the Huawei.
BT selected the cabinets they should have the same functionality. I think BT should be forced to say that it is not just line length and copper conditions - speed also depends on what cabinet type - I bet that would focus their minds.
~2 years trialling ECI GINP how long before they should get compensation from ECI and replace the cabs.
I do have symphony for BT in many areas but this is a screw up and they should do more.
When the original contract was signed, I don't think G.INP was a thing, so ECI won't be contractually bound to pay compensation for a technology which was developed after the initial roll out.
Openreach could have said to Huawei, we're not implementing G.INP so that it's the same acorss the board for all end users, but that would be stupid.
Post by: skyeci on February 28, 2017, 09:19:31 AM
Yes that's true BUT and its a big BUT BT are using substandard equipment in ECI cabinets, that is the point I think being made here.
If you are on Huawei cabinets then you have a superior service no matter how far you are from the cabinet or how many disturbers you might have. BT have a duty in my view to either fix it or replace the ECI estate with equipment which is not substandard. Now I guess the bean counters want ECI to fix the stuff but it seems likely that their design is so flawed that this is unlikely to be possible at least in the short term. If it cannot be fixed then as it is not fit for purpose ECI shold be made to pay a significant refund to BT which might just allow something else to be done.
Stuart
My thoughts exactly. We pay the same we should get the same but we dont.
Eci users should get a discount if anything due to not getting the same services as huawei users.
Post by: Black Sheep on February 28, 2017, 09:22:38 AM
When the original contract was signed, I don't think G.INP was a thing, so ECI won't be contractually bound to pay compensation for a technology which was developed after the initial roll out.
Openreach could have said to Huawei, we're not implementing G.INP so that it's the same acorss the board for all end users, but that would be stupid.
That is a very good point.
Post by: Ronski on February 28, 2017, 10:18:53 AM
Hi
I doubt BT are worried about this scenario, for a start no one can prove anything as you can't swap out from an ECI cab to an Huawei to prove what speed you would get. Plus VDSL has many variables nothing is guaranteed.
Yes some people can, one forum member here has already done just that. There are a number of ECI cabs round here with Huawei twins, mine included, once it's live I intend to swap. This will become more common as BT clearly appear to have stopped installing ECI cabs, I wonder why. .......... may be they realise they offer a substandard service.
http://forum.kitz.co.uk/index.php/topic,18678.msg335200.html#msg335200
Post by: Chrysalis on February 28, 2017, 11:02:02 AM
So based on that I see 2 scenarios.
1 - ECI written an update to address the issues raised last year, and openreach sat on the update as they have a limited testing schedule, they started testing it this year prior to the expected march rollout and found a new problem they decided they cannot ignore.
2 - Several updates have been done but each keeps getting issues, and the latest one is the one andyhcz leaked. This however makes less sense as if they all kept having less problems why previously announce it was going ahead this spring?
I also believe when the rollout was underway with the M41s, BT were not even thinking of g.inp and vectoring, their concern was simply rolling out VDSL2 as quickly and cheaply as possible and its this reason I believe ECI have not broken their contract, BT are now simply asking them for some spec enhancement that wasnt originally thought about due to the short termism. Speculation on my part, based on what we know already. As someone else said this is probably a very low priority issue for BT, as g.inp does not affect the product they are marketing, it meets ASA requirements for a 80/20 product. The only business case for g.inp is that it can reduce fault reports as the technology is quite good at masking issues on lines.
The way to make you realise the situation is not as bad as it could have been is that without the cheaper ECI cabinets I expect the commercial rollout would have covered less properties, and I certainly prefer a ECI based VDSL service over either ADSL or cable broadband.
What about the viability of running a 3db target without g.inp? its viable. As shown on ADSL but I am not sure if they will risk it as I think fault reports will inevitably increase. My own opinion is that the best boundaries for SNRM targets is 1,4,7,10 db and so on not 3,6,9. My own line has comparable error rates with a 4.5db snrm vs a 6db snrm. If my theory is right it would increase when dropping below 4db but anything above 4db it will have a comparable ES rate to 6db.
Post by: skyeci on February 28, 2017, 11:29:39 AM
Told the wife we need to move house ::)
Post by: ktz392837 on February 28, 2017, 11:34:28 AM
Openreach could have said to Huawei, we're not implementing G.INP so that it's the same acorss the board for all end users, but that would be stupid.
Yes stupid like getting two suppliers supply such different quality of hardware.
The way I look at without GINP and without 3db ECI users are looking at 20-30% less speed this needs to be taken into account in any advertising of the product.
Also it may not have been in the original contract but i doubt ECI have implemented (or not as the case appears) GINP for free.
I get it that it is just tough luck but I do not need to agree with it.
Post by: lee111s on February 28, 2017, 11:45:08 AM
Yes stupid like getting two suppliers supply such different quality of hardware.
The way I look at without GINP and without 3db ECI users are looking at 20-30% less speed this needs to be taken into account in any advertising of the product.
Also it may not have been in the original contract but i doubt ECI have implemented (or not as the case appears) GINP for free.
I get it that it is just tough luck but I do not need to agree with it.
So should Openreach remove G.INP and the 3db functions from Huawei cabs so that it's fair for everyone?
It's likely one supplier couldn't meet the demands of Openreach when they first started to deploy, therefore 2 were used. Not only that, both vendors were able to supply what was required at the time.
The issue here is an ECI issue. Openreach couldn't have predicted the future to see that ECI cabs would suffer the issues they do.
Post by: Bowdon on February 28, 2017, 11:54:29 AM
Yes some people can, one forum member here has already done just that. There are a number of ECI cabs round here with Huawei twins, mine included, once it's live I intend to swap. This will become more common as BT clearly appear to have stopped installing ECI cabs, I wonder why. .......... may be they realise they offer a substandard service.
Does the huawei twins show up as seperate cabinets on the maps/lists or is it just included in the ECI listing?
All but one cabinet in my town is ECI. The only Huawei one was put in by BDUK, and was the most recent one.
I might start an ECI Club! ;D
Post by: Ronski on February 28, 2017, 01:26:38 PM
Does the huawei twins show up as seperate cabinets on the maps/lists or is it just included in the ECI listing?
Not quite site what you mean by the above, on my map I've just added a comment to the cab that it has a Huawei twin.
NDBRO18 and NDRAM 6 both have Huawei twins installed, NDBRO 6 should also by now, and I think NDBRO 23 may have.
Post by: PhilipD on February 28, 2017, 03:10:25 PM
Yes some people can, one forum member here has already done just that. There are a number of ECI cabs round here with Huawei twins, mine included, once it's live I intend to swap. This will become more common as BT clearly appear to have stopped installing ECI cabs, I wonder why. .......... may be they realise they offer a substandard service.
http://forum.kitz.co.uk/index.php/topic,18678.msg335200.html#msg335200
That is a very rare exception and again only the same people here complaining of this will ever remotely consider trying it just to swap to a Huawei cabinet. Out of the millions of customers how many do you think are going to do this?
Regards
Phil
Post by: PhilipD on February 28, 2017, 03:22:41 PM
My thoughts exactly. We pay the same we should get the same but we dont.
Eci users should get a discount if anything due to not getting the same services as huawei users.
But no one gets the same guaranteed speeds or performance levels anyway regardless of the type of cabinet.
So lets say for argument there is one ECI cabinet that by luck everyone connected to is less 300 Metres distance and they all enjoy 80/20 on fastpath. A Huawei the other end of town mainly serves properties some distance away and the majority of customers are connected slower than 80/20 and most are higher latency due to interleaving. You are suggesting the ECI cabinet people should receive a discount, how is that fair in that circumstance?
My point is, there are bigger variables in a persons sync speed than just the fact they are connected to one make of cabinet or the other, but no one receives discounts because their line fairs a bit worse than someone else's. The only option is a reduced speed product.
If BT were forced to give discounts to customers on ECI cabinets all they would do is turn off G.INP on Huawei cabinets to create a level playing field to avoid messing around with discounts.
Regards
Phil
Post by: Ronski on February 28, 2017, 03:55:32 PM
Hi
That is a very rare exception and again only the same people here complaining of this will ever remotely consider trying it just to swap to a Huawei cabinet. Out of the millions of customers how many do you think are going to do this?
Regards
Phil
I was just pointing out it is possible, can't means it can't be done, no matter how rare it is even just one person doing it means it can.
I do realise that they are not going to rip out eci cabs, or discount eci lines, but that doesn't mean we have to be happy about it, I'm also not over the moon about the fact that I get a slower speed than others, but then others get less than me. The only way that would change is if we get full fibre*, which we will do as Virgin is going be rolled out around here. .....supposedly. * not sure if that will still entail coax though with virgin.
I'm not planning on changing cab types solely because of the switch to Huawei I'm also hoping I'll end up with a better performing line. I'm approximately 450 to 500 meters from the cab, yet I currently get 47/6. Used to get 12 up, but that's slowly dropped, down stream has fluctuated but overall has stayed around same.
Post by: skyeci on February 28, 2017, 03:57:26 PM
Post by: Dray on February 28, 2017, 03:59:22 PM
Post by: broadstairs on February 28, 2017, 05:21:01 PM
Stuart
Post by: Bowdon on February 28, 2017, 06:32:47 PM
The ECI cabinet, by todays standard, is inferior. Because its not able to be upgraded (so far).
But as others have said BT won't do anything unless the gap becomes noticable to the general public, and if a big public fuss is made about it.
From what I understand by previous replies to my posts if ECI people get G.fast then they should be at an equal performance as Huawei G.fasters. If I'm wrong about this then let me know.
Post by: ejs on February 28, 2017, 06:47:52 PM
If all people are going to do with their speed is compare it to other people's, then most of them will always be unhappy, there will always be people getting a better speed on a better type of cabinet or because their phone line is of better quality or because fewer people have signed up for FTTC on their non-vectored cabinet or various other reasons. If their speed is good enough for what they want to do with it, it might not really matter whether or not someone else is getting more or less than what they're getting.
Post by: Ronski on February 28, 2017, 06:59:15 PM
If proper fibre comes to Thanet then I will swap :fingers: . Broadstairs used to have cable TV back in the 60's ;)
Stuart
It was called Rediffusion, still lots of properties with the cables strung along them.
@EJS I think all Huawei cabinets should have vectoring enabled, and yes it would give us ECI end users something else to complain about ;)
Post by: ktz392837 on February 28, 2017, 08:57:33 PM
From what I understand by previous replies to my posts if ECI people get G.fast then they should be at an equal performance as Huawei G.fasters. If I'm wrong about this then let me know.This is true but at 400-500m distance Gfast is unlikely to help me during the first rollout would need a pod closer and even if it it did I suspect a gfast connection is going to be much more expensive when a connection on FTTC using Huawei cabinet would be fine.
Post by: lee111s on February 28, 2017, 09:16:16 PM
We're not talking about people getting 80/20 on either cabinet. We are talking about people at 400 to 500 metres away. On at ECI cabinet they might get 55Mb's while the Huawei with G.INP is getting 65Mb - 70Mb. So the ECI user is possibly getting 10 to 15Mb less because of no G.INP.
The ECI cabinet, by todays standard, is inferior. Because its not able to be upgraded (so far).
But as others have said BT won't do anything unless the gap becomes noticable to the general public, and if a big public fuss is made about it.
From what I understand by previous replies to my posts if ECI people get G.fast then they should be at an equal performance as Huawei G.fasters. If I'm wrong about this then let me know.
Current VDSL cab vendor is completely unrelated to what, if any, G.fast pod will be added to the side of the PCP.
Post by: Bowdon on February 28, 2017, 09:31:36 PM
If all people are going to do with their speed is compare it to other people's, then most of them will always be unhappy, there will always be people getting a better speed on a better type of cabinet or because their phone line is of better quality or because fewer people have signed up for FTTC on their non-vectored cabinet or various other reasons.
It's not about speed. It's about having the same chance as everyone else. If the cabinets were able to use the same technology then nobody would be complaining cabinets. There will of course be the general complaining because people always want better and faster broadband quality. But the biggest complaint of an inferior technology wouldnt be one of them.
If Huawei can get vectoring then go for it. ECI people aren't wanting to hold others back. We're just wanting our ECI cabinets to be up to date.
Maybe if Hauwei got vectoring it would cause a bigger speed difference between the 2 and the ECI public might wake up and start complaining.. so inadvertently it would help the ECI people too.
BTW, I'm not talking from an anti-BT position here. I'm just on about fairness.
Post by: burakkucat on February 28, 2017, 09:40:54 PM
Current VDSL cab vendor is completely unrelated to what, if any, G.fast pod will be added to the side of the PCP.
My understanding is that the approved vendors for the Openreach G.Fast deployment are Huawei and Nokia-Lucent (or is it Nokia-Alcatel or just Nokia?) and, as you say, totally unrelated to the manufacturer of the local cabinet based MSAN/DSLAM.
Post by: Ktor on March 01, 2017, 02:20:07 AM
The only business case for g.inp is that it can reduce fault reports as the technology is quite good at masking issues on lines.
Errm. Seems fairly obvious to me the business case for G.INP was to get more speed/reliability out of crappy connections to increase the number of customers they can flog TV services to.
Post by: lee111s on March 01, 2017, 09:33:13 AM
Errm. Seems fairly obvious to me the business case for G.INP was to get more speed/reliability out of crappy connections to increase the number of customers they can flog TV services to.
Openreach don't sell TV services.
Post by: broadstairs on March 01, 2017, 09:37:00 AM
Openreach don't sell TV services.
No but BT do and that's the issue with OR being part of BT, this crossover potential for BT to pressure OR to do things which help the overall group. OR should have a remit to do things because they are effective for all not just the BT group and no matter how much they (OR) say that's what they do while they are part of the same group people will not believe it actually works that way.
Stuart
Post by: PhilipD on March 01, 2017, 10:55:19 AM
G.INP does two things:
1) Corrects errors on UDP packets that otherwise would be lost if noise on the VDSL line caused the packet to be corrupted. This is important for voice/video services that use UDP. UDP is a light weight protocol and there is no way to re-request a UDP packet if one is missing due to an error, and if there was a way, by the time the request has gone all the way back to the originating server and been resent, in real time applications that means it arrives back two late and is of no use anyway. Interleaving of course helps here anyway by adding error correction, but packets can still be lost if the error can't be corrected. G.INP is simply a buffer at the VDSL cabinet modem that holds on to frames for a short while after they have been sent, and a low latency data exchange between the modems is able to signal back to the cabinet and say "this frame is corrupt, send again", and its sent with very low latency from the buffer so can work with real time applications.
2) For all other data exchanges using TCP/IP then corrupted packets aren't lost, as there is a mechanism to request the packet again, this would go back to the originating server which then re-transmits the packet. The packets are reassembled in the correct order when received even if arriving out of sync. This is why web pages and downloads are not corrupt even though our modem stats are showing errors. The problem with this is, over millions of connections re-transmitting errors adds up to a lot of extra bandwidth and overheads. By using G.INP, the frame containing the corrupt packet is re-requested from the cabinet modems buffer and the network stack never sees the error, so doesn't have to send a re-transmit request back to the originating server, so removing those overheads of re-sending data from source to recipient.
For 2, this is why interleaving is turned on even when the errors aren't particularly noticeable or causing a problem for the end user, as it helps remove the extra overheads by reducing the errors as much as possible. As G.INP does the same thing but better is the reason why the DSLAM is allowed to turn interleaving off when G.INP is available. The same error rate exists whether G.INP is on or off, but as G.INP stops those errors causing overheads on the network, BT are quite happy disabling interleaving when G.INP is available unless things are so bad both are required.
Regards
Phil
Post by: g3uiss on March 01, 2017, 05:26:06 PM
All agreed it's just good to have, or it least was for me on a long AL line
Tony
Post by: skyeci on March 01, 2017, 05:44:55 PM
https://www.openreach.co.uk/orpg/home/updates/briefings/super-fastfibreaccessbriefings/sffabriefings.do
Post by: NewtronStar on March 01, 2017, 09:02:28 PM
Post by: DMZ on March 02, 2017, 11:25:52 AM
I'm not adding much to this conversation but it's something to give you all a chuckle.
I was passing my ECI cabinet today and me being me, I gave it a quick kick. Then someone said "I don't blame you, these cabinets have gone to the dogs really." It was an Openreach fella parked in the alley around the corner from it. I did question this; Anymore ECI cabinets? Since this one is at full capacity. Openreach fella: "Nah definitely a Huawei cabinet next."
I walked away with a smile and a wave knowing I got away with teaching my ECI cabinet a thing or two. And the fact this Openreach guy doesn't think much of them either. Getting a new Huawei cabinet installed too. May say a lot or little. ;D
Sorry for the not so serious post but it was something I wanted to share. Plus in actuality I don't mind being on an ECI cabinet it works, I can do everything I need to without an issue. Even when it's as full as a gun so...Yup. I'm just immature I HAD to kick it today. :cool:
Post by: Ktor on March 06, 2017, 01:19:02 AM
Openreach don't sell TV services.
Yet the only people left with G.INP on ECI cabinets after they 'removed' the update were those with BT TV services.
Post by: lee111s on March 06, 2017, 07:44:50 AM
Yet the only people left with G.INP on ECI cabinets after they 'removed' the update were those with BT TV services.
And?
Post by: Chrysalis on March 22, 2017, 04:19:55 PM
A new firmware has been developed and testing will start over the summer.
If testing has good results then a rollout may happen this autumn (not next april).
Post by: ejs on March 22, 2017, 04:29:55 PM
Post by: Chrysalis on March 22, 2017, 04:40:23 PM
Post by: skyeci on March 22, 2017, 05:36:34 PM
Post by: ktz392837 on March 22, 2017, 09:27:18 PM
Here is an update regarding ECI G.INP
A new firmware has been developed and testing will start over the summer.
If testing has good results then a rollout may happen this autumn (not next april).
Great news and I am glad at least BT are trying to sort the problems. I still wish BT speeded up the process a bit though.
Post by: WWWombat on March 23, 2017, 01:00:59 PM
I still wish BT speeded up the process a bit though.
ECI are probably being forced to go through complete regression tests on every cycle now. I bet they wish BT would speed up the process too. But there's no chance of that now...
Post by: Bowdon on March 23, 2017, 11:45:20 PM
Here is an update regarding ECI G.INP
A new firmware has been developed and testing will start over the summer.
If testing has good results then a rollout may happen this autumn (not next april).
That's good news!
Hopefully if the firmware comes out then ECI might catch up fast. It's like we're all waiting behind a big hurdle.. hoping we can clear it.
Post by: ktz392837 on May 21, 2017, 06:16:17 PM
Post by: burakkucat on May 21, 2017, 06:43:16 PM
Does anyone have any recent information on the ECI GInp and 3db rollout situation?
No new information has come my way . . . :no:
Post by: ktz392837 on September 01, 2017, 06:04:46 PM
Post by: skyeci on September 01, 2017, 07:25:20 PM
Post by: Ixel on September 02, 2017, 12:46:19 AM
Post by: burakkucat on September 02, 2017, 01:14:35 AM
Post by: skyeci on September 02, 2017, 06:25:10 AM
"The ECI RETX fix has been delivered and extensively tested. It is being included in a full update to the network and this full release is under test. As you will appreciate there is an extensive formal test and release process to go through before such major new functionality is deployed in our live network. A network pilot, including CP’s is currently being planned with the CP’s for Summer 17 with the earliest decision being Autumn 17. There is likely then to be a controlled ramp up of deployment of the ECI RETX functionality into the network.
So it is planned and is in progression but it maybe several months before it is available at your address"
Post by: j0hn on September 02, 2017, 12:45:55 PM
Sounds like good progress :fingers:
Post by: skyeci on September 02, 2017, 12:56:10 PM
I shared it here in June of this year. :fingers:
So I was provided this update from Openreach today and given permission to share with regards to ECI G.INP. sounds like its been fixed
Post by: Chrysalis on September 02, 2017, 03:52:32 PM
Post by: Bowdon on September 03, 2017, 12:59:14 PM
I'm still on version 0xb206.
Post by: ejs on September 03, 2017, 01:20:58 PM
Those two bytes usually labelled as the "chipset version" are merely "vendor specific information" according to the standards, so they might change when some part of the cabinet firmware gets updated, but not necessarily.
Post by: Chrysalis on September 03, 2017, 04:56:54 PM
the chipset version seems to be actually the firmware version, the name is misleading.
Post by: ejs on September 10, 2017, 07:08:14 AM
Quote from: BTWholesale.com
Openreach ECI Retransmission Trial DELAYED | BB-3087-17
Secure content found, please log in to access.
Last updated date: 08/09/2017 | Briefings | Data Services
Post by: Ixel on September 10, 2017, 10:59:43 AM
[Moderator edited to remove an empty quotation block.]
Post by: WWWombat on September 10, 2017, 11:36:05 AM
Wonder what happened.
Post by: Chrysalis on September 10, 2017, 12:06:23 PM
Post by: PhilipD on September 11, 2017, 09:59:47 AM
I expect ECI will get no more business from BT in future, g.inp is an established dsl technology that has been around for almost a decade and they cannot even implement it in their firmware properly.
It's odd it was working and seemed to get through testing the first time and was deployed, and it was working great for me. The basics are there, but obviously there seems to be some issue or compatibility problem again.
BT are to blame though, they should never deploy equipment lacking functionality they know they will enable or want to enable during that equipment lifespan. As you say G.INP is nothing new, there should be no reason why it wasn't on and working from the very first VDSL connection. The same situation applies to vectoring, which is never likely to see wide deployment now, and if you are on an ECI cabinet, forget it.
Regards
Phil
Post by: kitz on September 11, 2017, 10:55:21 AM
Quote
It's odd it was working and seemed to get through testing the first time and was deployed, and it was working great for me.
Seemed to work fine for most of us with BCM chipsets.
What we don't know what effect it is having on say the unhacked ECI modems because we have no way of monitoring. The existing DLM bodge repair was due to ECI modems and HH5A on the Huawei cabs. There are likely to still be a lot of users out there with ECI modems. It looked like BT could have been trying to update the f/w on the HH5A's. Didnt we see something just a few weeks back that implied they may be?
Post by: j0hn on September 11, 2017, 01:25:10 PM
Quote from: kitz
It looked like BT could have been trying to update the f/w on the HH5A's. Didnt we see something just a few weeks back that implied they may be?BlackSheep had G.INP applied to the upstream of his HH5A. He said it made his line unstable and he had to perform a DLM reset.
I thought the ECI DSLAM's were only capable of G.INP on the downstream though. Is that correct? That should make the recent HH5A firmware update irrelevant unless it also targeted downstream G.INP compatibility with ECI DSLAM's.
Post by: ktz392837 on September 11, 2017, 02:45:34 PM
[Moderator edited to remove an empty quotation block.]
Post by: Black Sheep on September 11, 2017, 03:10:17 PM
BlackSheep had G.INP applied to the upstream of his HH5A. He said it made his line unstable and he had to perform a DLM reset.
I thought the ECI DSLAM's were only capable of G.INP on the downstream though. Is that correct? That should make the recent HH5A firmware update irrelevant unless it also targeted downstream G.INP compatibility with ECI DSLAM's.
Ummm, I actually said it was the downstream SNR that was set to 'sub 6dB' that was making my line 'flappy'. I lost the ReTx when I performed a full DLM re-calc, but it returned after the expected 3 day wait. :) :) :)
Post by: j0hn on September 11, 2017, 03:21:21 PM
Post by: Black Sheep on September 11, 2017, 03:36:06 PM
As the regulars will know, I don't monitor my circuit really ..... it was only when the drops were happening every day that I decided to 'Ave a gander' and noticed my DS SNR was at 3dB. I assumed this was the culprit, and reset it to the default 6dB and haven't had a problem since ??.
Yes, I've lost about 10Mbps from the SNR increase, but stability is absolute key to me. As I've said before, if I could I'd give more of my speed away to those less fortunate. I really don't need it all. ;D :) :)
Post by: Ixel on September 14, 2017, 09:39:02 AM
Just a note here to say the situation is not as bad as feared, will leave it at that.
You mean we may still see G.INP on ECI before the year is up? :P
Post by: ktz392837 on September 14, 2017, 12:05:24 PM
I estimate I would gain around 5mb for Ginp and perhaps 10mb for 3db (possibly 7.5mb without ginp) either way both worthwhile.
I hope further details will be made available on new timescales and what the problem actually is this time.
Post by: kitz on September 14, 2017, 01:12:16 PM
BlackSheep had G.INP applied to the upstream of his HH5A. He said it made his line unstable and he had to perform a DLM reset.
iirc it was the Target SNRM of 3dB that he had issues with, rather than G.INP ?
Quote
I thought the ECI DSLAM's were only capable of G.INP on the downstream though. Is that correct?
That should make the recent HH5A firmware update irrelevant unless it also targeted downstream G.INP compatibility with ECI DSLAM's.
Supposedly so.
An update would be beneficial though to those on Huawei cabs so they could take advantage if DLM decides the line needs it.
If DLM does decide the line needs some action to stabilise upstream and the modem is incapable of upstream retransmission, its alternative is putting on quite a high rate of INP on the upstream.. which also appears to impact downstream speeds. So in theory it would be much better for those on Huawei cabs if both the HH5A and ECI modems were capable of upstream G.INP.
Post by: skyeci on September 14, 2017, 01:28:55 PM
I really hope both ginp and 3db is not dead for eci cabinets. If ginp isn't possible I hope that 3db will still be on the cards.
I estimate I would gain around 5mb for Ginp and perhaps 10mb for 3db (possibly 7.5mb without ginp) either way both worthwhile.
I hope further details will be made available on new timescales and what the problem actually is this time.
Pretty sure you would need g.inp before getting the lower snr profiles.. only 17 months have passed since since it was removed from my line.... it's not looking good really....
Post by: kitz on September 14, 2017, 03:13:00 PM
Which is as you say a shame, but I can perhaps understand why. My line sat quite happily at 3.2dB for a few weeks after I resync'd before one of my x-talkers. I know Im far from the only one whose line manages fine at the lower SNRm
Post by: Chrysalis on September 14, 2017, 03:18:06 PM
Post by: ktz392837 on September 14, 2017, 04:52:57 PM
Pretty sure you would need g.inp before getting the lower snr profiles.. only 17 months have passed since since it was removed from my line.... it's not looking good really....I agree it makes sense to have ginp before 3db but my line last held on at 1.5db for 27 days and apart from a car passing the cabinet in a way the cabinet didn't like that reset me back to 6db I suspect I could hold on to the 1.5db again for multiple weeks until the same car passes again.
I am trying to avoid saying it but these eci cabs were a very poor decision. They should be replaced.
Trying to stay positive but the usual let's keep the problems secret and the public are stupid attitude from BT really annoys me.
I guess BT is just hoping that I will pay double for Gfast to get the speed I should be getting on a cabinet that works well - I won't be. I will be focusing my effort to ensure no one gets gfast that's if we get gfast in the first place.
Basically the opposite of when fttc arrived but before it took them 2+ years to connect the power to the cabinet that we now find does not actually work!
Post by: PhilipD on September 14, 2017, 05:56:27 PM
I guess BT is just hoping that I will pay double for Gfast to get the speed I should be getting on a cabinet that works well - I won't be. I will be focusing my effort to ensure no one gets gfast that's if we get gfast in the first place.
If your line is such that you aren't getting 80/20 on FTTC then the likelihood is Long Range G.Fast will not be any faster, likely slower, if offered to you at all.
Why we are still messing around in 2017 trying to send data down decades old audio only telephone cable, that was never that good at audio let alone data, beggars belief.
Regards
Phil
Post by: kitz on September 14, 2017, 07:53:01 PM
Quote
I am trying to avoid saying it but these eci cabs were a very poor decision. They should be replaced.
With respect (and remember I'm on an ECI cab knowing that I would fare much better on a Huawei cab & getting higher speeds), I really don't know where the blame lies on this.
1) BT has always gone for diversity. For a company of their size it makes business sense not to rely on one manufacturer. Going right back to the days when ADSL very first started they used different manufacturers. Ive been around long enough to know that at one time the Juniper DSLAMs were better than many of the others and less problematic when 2Mbps adsl was introduced.
Moving on to maxdsl and adsl2+, all of a sudden there were issues with the Marconi MSANs in that they couldn't cope with the higher upstream speeds- yet previously the Marconi MSANs were cutting edge for rate adaptive dsl. Go back in time and they also had system X and system Y for telephony.
2) Ironically ECI was cutting edge when it came to VDSL. In 2012 they were considered the better VDSL dslams. iirc ECI made a lot of progress in vectoring dslams. Problem being they weren't on the M41's.
Huawei late had the edge in that they were bigger units and therefore the backplanes could be upgraded to install a vectoring unit. ECI had gone for try make the cabs as small as possible for the M41's which as the time was a good thing as they could hold more users floorspace wise.. which was also good when you had several districts complaining how ugly VDSL cabs were.
3) BT were not the only telco caught up in the ECI problem, Duetche Telekom was another, but there were more. iirc Duetche Telecom had to upgade many of their cabs to V41s.
Finally Im not chuffed that Im on an ECI, so I really have no reason to defend them just trying to explain some of the history and that 5+yrs ago then ordering ECI wasn't so stupid as what it seems without the benefit of hindsight. I'm really struggling this week, I still have to do a LOT of admin behind the scenes that no-one sees so I'm just typing whilst I can which is very slow. I'm sure ejs will correct anything I remember incorrectly and can add links if need be as Ive just blurbed.
Post by: burakkucat on September 14, 2017, 09:37:54 PM
ECI had gone for try make the cabs as small as possible for the M41's which as the time was a good thing as they could hold more users floorspace wise..
For posterity, I'll document the official ECI name of the product in question --
Hi-FOCuSTM M41 Mini-Shelf
Notice the last two words, conjoined with a hyphen.
Quote from: ECI Telecom
The M41 Mini-Shelf provides a full range of triple play services in a compact, durable, and user-friendly shelf. Specifically designed to fit in cramped areas with harsh environmental conditions, such as street cabinets, communications rooms, and basements, the M41 Mini-Shelf is highly flexible and versatile, minimizing deployment costs.
I have a few documents available --
- Hi-FOCuS M41 Mini-Shelf Data Sheet (dated 2006)
- Hi-FOCuS M41 Mini-Shelf General Description (dated 2006)
- Hi-FOCuS M41 Mini-Shelf Product Note (dated 2010)
- Hi-FOCuS V41 Vectoring Shelf Product Note (dated 2012)
Post by: smallal on October 02, 2017, 11:19:56 AM
Article here: https://www.ispreview.co.uk/index.php/2017/09/openreach-test-xdb-speed-boost-eci-fttc-fibre-broadband-lines.html
Post by: j0hn on October 02, 2017, 12:35:28 PM
Looks like BT Openreach are going to start testing the ECI fix, along with a 3db SNR profile, from Oct 20th.
Article here: https://www.ispreview.co.uk/index.php/2017/09/openreach-test-xdb-speed-boost-eci-fttc-fibre-broadband-lines.html
That article came from this thread
http://forum.kitz.co.uk/index.php/topic,20346.0.html
Also, the article doesn't say anything about g.inp.
This lower margin trial is unrelated to g.inp, and definitely not run along with each other
Post by: kitz on October 02, 2017, 03:53:19 PM
If all goes well, expanded to 50k lines in Dec, so bit of an anticlimax really.
Post by: ktz392837 on November 07, 2017, 02:03:55 PM
Post by: skyeci on November 07, 2017, 02:25:06 PM
Post by: ktz392837 on November 07, 2017, 03:55:55 PM
Assuming 50 users per cab that would be 200 cabs per day. Assuming 25 cabs per exchange that would be 8 exchanges per day. Call it 10 exchanges per day with 5500 exchanges that would be 550 days!
Any better guesses how long the rollout will take?
Anyone with contact able to hint on whether the rollout is taking place or not ;)
TIA
Post by: skyeci on November 07, 2017, 04:35:46 PM
Post by: j0hn on November 07, 2017, 06:24:06 PM
edit: to add to that...
Quote
Openreach ECI Retransmission Trial DELAYED | BB-3087-17It never restarted since that update.
Last updated date: 08/09/2017
Only news I've seen since then was Andy over on TBB saying the rollout was underway, but he didn't even know about the above delayed update. His info contradicted himself.
Post by: j0hn on November 07, 2017, 06:34:30 PM
Quote
Assuming 50 users per cab that would be 200 cabs per day. Assuming 25 cabs per exchange that would be 8 exchanges per day. Call it 10 exchanges per day with 5500 exchanges that would be 550 days!There's more than an average of 50 users per cabinet. Seeing as the ECI cabinets were part of the early commercial rollout they are likely the fullest cabinets.
Post by: WWWombat on November 07, 2017, 11:02:57 PM
There's more than an average of 50 users per cabinet. Seeing as the ECI cabinets were part of the early commercial rollout they are likely the fullest cabinets.
8.6m users, on 84k cabinets, so average now just over 100 users per cab.
But, since ECI barely figured in the BDUK rollout, ECI might have made 40% of the 52k commercial cabs - so perhaps 21k cabs.
If they have average takeup, they'd home 2 million subs. If we expect them to be fuller, and allow 150 subs per cab, then we have just over 3 million ECI subs.
Post by: ktz392837 on November 08, 2017, 12:11:25 AM
Post by: Chrysalis on November 08, 2017, 07:19:14 AM
Post by: skyeci on November 08, 2017, 11:57:41 AM
This is with permission from a chief engineer within openreach who I have had previous contact with before specifically about g.inp on eci...
""The ECI G.INP functionality has been included in a new trial on ECI equipment. The Trial is looking to reduce the SNRM on certain lines where this does not impact on performance. G.INP has been included in that trial. The application of retransmission on ECI cabs is currently in trail on circa 30000 lines across the country. The trial will run for several months to truly assess the impact before a decision is made on whether to deploy to a further Pilot and then nationally. Given previous experience I expect we will be taking a cautious approach""
Post by: Ixel on November 08, 2017, 12:04:04 PM
Oh dear... further long wait to come by the looks of it..:(
This is with permission from a chief engineer within openreach who I have had previous contact with before specifically about g.inp on eci...
""The ECI G.INP functionality has been included in a new trial on ECI equipment. The Trial is looking to reduce the SNRM on certain lines where this does not impact on performance. G.INP has been included in that trial. The application of retransmission on ECI cabs is currently in trail on circa 30000 lines across the country. The trial will run for several months to truly assess the impact before a decision is made on whether to deploy to a further Pilot and then nationally. Given previous experience I expect we will be taking a cautious approach""
Oh no. This looks like it'll be well over a year before any possibility, two or more if there's further issues (or never). By the time G.INP is rolled out to ECI G.fast might be the the next technology available for many. ECI is a complete failure for Openreach it seems. What I don't understand is why they need several months to assess it, surely 3 months of data is adequate?
Post by: daveesh1 on November 08, 2017, 04:20:14 PM
Post by: WWWombat on November 08, 2017, 11:55:39 PM
ECI is a complete failure for Openreach it seems.
It is certainly a complete breakdown of trust. BT simply don't trust ECI's quality control processes - that what they say they've fixed is actually fixed and tested. *And* that they haven't broken something else.
The current test cycle (s l oooooo w) is a consequence.
What I don't understand is why they need several months to assess it, surely 3 months of data is adequate?
I believe that BT employ a network freeze for Christmas - quite possibly for the entirety of December.
In a test like this, then, they need to be able to roll out the change, and be happy it finished successfully, while still allowing enough time to undo the rollout completely before the freeze starts.
From the most recent report, I suspect that BT have decided they're happy to leave "a few" running over winter, and will aim to rollout properly next year. In the meantime, ECI probably get to do a fair statistical analysis on the outcome.
Aside: (The reports on progress earlier this autumn actually made me doubt "the freeze", as it looked certain that BT would have to run into this period. I'm "relieved" to hear the current status, at least as far as my understanding of BT's behaviour goes).
Post by: smallal on January 17, 2018, 09:47:03 AM
It should only have taken months, not years, to fix but that's BT for you.
Lets face it, ECI should have been forced to redesign & supply new cards for the cabinets.
And still we wait, has the trial restarted yet?
Post by: skyeci on January 17, 2018, 10:38:05 AM
Post by: S.Stephenson on January 17, 2018, 11:12:39 AM
Post by: smallal on January 17, 2018, 11:17:18 AM
At least then some customers may get the speeds they're actually paying for!
Post by: Chrysalis on January 17, 2018, 01:36:12 PM
The case of BT not using available technology is a probable no go as well, as BT can just say they tried but their supplier failed hence it been out of their control.
It sucks, and I hope BT have learned their lesson in using non prime chipsets in future, I dont think they will ever stop the double supplier in the field policy tho. But it could be worse, we could all still be stuck on ADSL, I believe the cheaper ECI cabinets is what made some areas considered commercially viable for FTTC in the first place.
Post by: Ktor on January 17, 2018, 02:38:34 PM
As brutal as it sounds, noone pays for a guaranteed speed.
Apart from a bit from Virgin in some areas openreach have no competition and don't give a rat's arse. That is what is brutal.
(and they screwed up my cabinet 2 years ago on 22nd March).
Post by: broadstairs on January 17, 2018, 03:12:29 PM
Stuart
Post by: j0hn on January 17, 2018, 03:55:24 PM
Quote
It sucks, and I hope BT have learned their lesson in using non prime chipsets in futureAt the time of OpenReach picking vendors, ECI were seen as 1 of the front leaders in VDSL2.
Perhaps they should have went with the more expensive ECI V41 DSLAMs, but no idea how OpenReach were supposed to see in to the future and predict these issues.
To me the blame lies entirely with ECI.
You can bet your right bollock that OpenReach are pushing ECI as hard as they can to get this sorted.
Post by: kitz on January 17, 2018, 04:36:17 PM
At the time of OpenReach picking vendors, ECI were seen as 1 of the front leaders in VDSL2.
Perhaps they should have went with the more expensive ECI V41 DSLAMs, but no idea how OpenReach were supposed to see in to the future and predict these issues.
To me the blame lies entirely with ECI.
You can bet your right bollock that OpenReach are pushing ECI as hard as they can to get this sorted.
At the time ECI cabs were considered superior :/ The line cards had more capacity and historically ECI had made some serious technological advances when it came to VDSL. Ironically vectoring! I know when I found out my new cab was an ECI several people said they were considered better than the Huaweis. ECI were known and respected by other Telco's outside of the UK.
It could have perhaps been a different story if Openreach had gone with the V41's - who knows?
I believe Deutsche Telekom may have now replaced all their M41's with V41's. Deutsche Telekom did exactly the same thing as Openreach in about 2010 and bought 2 different cab types mostly ECI - cant recall who their other manufacturer was but dont think it was Huawei.
Post by: Chrysalis on January 17, 2018, 05:35:31 PM
At the time of OpenReach picking vendors, ECI were seen as 1 of the front leaders in VDSL2.
Perhaps they should have went with the more expensive ECI V41 DSLAMs, but no idea how OpenReach were supposed to see in to the future and predict these issues.
To me the blame lies entirely with ECI.
You can bet your right bollock that OpenReach are pushing ECI as hard as they can to get this sorted.
possibly, but broadcom were the "safe bet" due to their longevity in the market and their reliability on other DSL technologies such as adsl.
The V41 should have been a no brainer as well, as by the point of the ECI rollout vectoring was a proven significant benefit. However I expect at that time of the rollout short term decisions were been made, it was a rollout of "lowest possible cost" rather than forward planning.
Looking at kitz post they were seen as a leader just because of capacity? I consider things like stability, compatibility, and features as technology superior rather than capacity, capacity is just something that allows a higher scaled rollout at lower cost. They even struggling to enable g.inp which is a decade old technology.
Post by: kitz on January 17, 2018, 05:59:35 PM
Looking at kitz post they were seen as a leader just because of capacity? I consider things like stability, compatibility, and features as technology superior rather than capacity, capacity is just something that allows a higher scaled rollout at lower cost. They even struggling to enable g.inp which is a decade old technology.
Read the whole sentence where did I say it was just because of capacity?
Quote
The line cards had more capacity and historically ECI had made some serious technological advances when it came to VDSL /snip/ ECI were known and respected by other Telco's outside of the UK.
ECI was the first DSLAM manufacturer to bring out system based vectoring. Historically they were respected by many other Telcos around the Globe for their ADSL equipment. Germany and France had been using them for years.
Quote
They even struggling to enable g.inp which is a decade old technology.
I dunno whats gone wrong with g.inp, whilst it may have been around for years.. originally it was PHYR invented by Broadcom.
We've seen Lantiq modems struggle with g.inp with the Huaweis.
There's the ASUS modems which dont work well with Huawei cabs, so much so that G.INP is switched off on Huawei cabs for anyone using those ASUS modems.
When Openreach did implement G.INP on the ECI's it worked fine for most of us here because we use BCM chipsets modems. Those using [hacked] ECI modems were reporting excellent results. The standard ECI/lantiq modems seemed to be ok, but no way of monitoring stats to be certain.
The ECI g.inp problems were with the non Lantiq and BCM chipset based modems eg Draytek, ASUS & even a Fritzbox.
Seems more like some sort of compatibility issue with certain modem chipsets. :(
Post by: kitz on January 17, 2018, 06:10:43 PM
Quote
It could have perhaps been a different story if Openreach had gone with the V41's - who knows?
DK also had problems with g.INP on all of their DSLAMS (both manufacturers) and as I said above "I believe Deutsche Telekom may have now replaced all their M41's with V41's," or at least during 2016 they were doing so. Now they have both vectoring and g.inp.
Post by: atkinsong on January 17, 2018, 06:35:14 PM
possibly, but broadcom were the "safe bet" due to their longevity in the market and their reliability on other DSL technologies such as adsl.
Going back to ADSL days, one of the most respected modems was the venerable Netgear DG834v3, which was eventually adopted by Sky as the first of their "all black" modem/routers. This was based on the Texas Instruments AR7 chipset. TI was then taken over by Infineon, who in turn passed their modem chipset business to Lantiq, who developed the AR7 into the current AR9. When Netgear released the DG834v4 it was Broadcom based and proved to be nowhere near as good as its forerunner.
The ECI g.inp problems were with the non Lantiq and BCM chipset based modems eg Draytek, ASUS & even a Fritzbox.
The Draytek 2760 series, 2860 series and 2862 series are all Lantiq based, are fully OR MCT conformant and fully support G.inp both ways and vectoring. During the initial rollout on ECI my 2760 was rock solid.
Post by: skyeci on January 17, 2018, 06:47:07 PM
Post by: kitz on January 17, 2018, 06:56:49 PM
... and there we have a problem.. because some modems just cant do upstream g.inp.
The Huawei cabs have to have separate rules in place.
- Downstream for most modems
- Upstream only if the modem is capable.
- OFF for certain ASUS modems.
The original purpose of G.INP was to enable better streaming of movies etc. The 'speed boost' by being able to correct errors on the fly and reducing RS overheads was just a byproduct. It was a downstream thing, thus done by the DSLAMs/MSANs. The modems being able to do so too for upstream was seen as a perk and why its still not deemed essential.
So we know ECI g.inp worked fine for certain lantiqs and it worked fine with the BCMs.... then we had reported problems whereby some modems were struggling to either get sync.. or were struggling to maintain sync and kept dropping out.
Now what if the problem is the M41's aren't capable of being able to cope with certain rulesets depending on which modem is in use. THAT would make more sense to me when it comes to disabling upstream g.inp.
Perhaps (just perhaps) the issue may not actually be with g.inp itself but trying to identify modems on the other end and what to do with them depending on the modems capability for g.inp.
Just something to mull over.
Post by: kitz on January 17, 2018, 06:59:06 PM
During the initial rollout on ECI my 2760 was rock solid.
Sorry I cant recall the model numbers now, but there were 2 of them. Draytek admitted defeat on those 2 models and offered a discount of £100 to owners of those models so they could purchase one of their newer models which would work with g.inp.
I was being lazy when I said Draytek, because it didnt apply to all models, I just couldnt recall the numbers.
Post by: kitz on January 17, 2018, 07:05:47 PM
supposedly if g.inp was/is broken ayeaye on mdws has managed to keep his g.inp from when it was first seen on ECI so it can't be all that bad. still seems odd Openreach left it enabled on some cabs etc after it was suspended.
It was broken for some modems - they never said which.
I'm not sure if it was left enabled on a per cab basis, but rather more per line basis. eg if the EU had BT-TV.. and thus most likely using a HH?
I'm sure I said at the time that they were leaving it on for users with TV services.
Post by: skyeci on January 17, 2018, 07:23:50 PM
yes I am sure you did and I understand why but. It just seems odd to leave it partially enabled for some. either turn it on or switch it off...its either broken or it's not ::) ;D
Post by: kitz on January 17, 2018, 07:40:56 PM
Quote
It just seems odd to leave it partially enabled for some.
Indeed, but to have done so means that they were confident it was working perfectly fine for those users.
So what makes them so special? OK so those using streaming IPTV are those who benefit most from g.inp.
<tin foil hat>
Most likely to be using HH which Openreach knows works OK.
</tin foil hat>
Post by: Ktor on January 17, 2018, 07:52:49 PM
So we know ECI g.inp worked fine for certain lantiqs and it worked fine with the BCMs....
If it were as simple as this modem or that modem why did they roll out to 1/4 million subscribers before noticing? Why didn't they already know about modems problems on Huawei cabs? If it is something simple why isn't it fixed two years on?
I don't think anyone outside openreach and ECI knows much about it.
So what makes them so special? OK so those using streaming IPTV are those who benefit most from g.inp.
g.inp lets BT flog IPTV services to a few more customers - that is why they bothered with it at all isn't it?
Maybe the line cards don't have enough processing power to implement g.inp on all channels at high sync rates.
Post by: ejs on January 17, 2018, 07:54:31 PM
All the Lantiq chipset modems, such as the BT HomeHub 5A and the ECI Openreach modem are now perfectly capable of doing upstream G.INP if BT bothered to update the modem firmware. In the early days, such firmware may not have been available, and so the SIN 498 requirements were probably written with the limitations of the modems at the time in mind.
Now what if the problem is the M41's aren't capable of being able to cope with certain rulesets depending on which modem is in use. THAT would make more sense to me when it comes to disabling upstream g.inp.
Perhaps (just perhaps) the issue may not actually be with g.inp itself but trying to identify modems on the other end and what to do with them depending on the modems capability for g.inp.
That sounds very unlikely to me. I thought all the logic of selecting what profile to use was done by some part of the DLM, and then the DSLAM in the cabinet simply does what it's told regarding enabling G.INP in whichever direction(s) on a particular line. I still think it's much simpler: just because the ECI M41s can do N tasks simultaneously, it's doesn't mean they will be able to do N+1 tasks simultaneously, even if the extra task may be relatively simple compared to all the things it's already doing.
I think part of the problem originates from BT never enforcing any modem compatibility rules, but I suppose it may originate from them having to fudge the system so that downstream G.INP, a mandatory requirement, is switched off until something detects your modem supports it, which was needed so that the Openreach modems could get a working network connection to update their firmware for G.INP support. So then if an Openreach person replaced one of their modems, with one that may have been sitting around in its box for a while, they might have to do a DLM reset, to switch off G.INP, so that the modem could connect, and then its firmware would update.
Post by: ejs on January 17, 2018, 08:01:16 PM
why isn't it fixed two years on?
It's taking a very long time to fix because they are now being extremely careful to avoid breaking anything if and when they try it again. I'm sure they already what the problem was and which modem(s) were involved. I thought they said a while ago that they'd developed a fix. But if they do something, it will then be their fault if something goes wrong, so it's much safer for them to just do nothing and forget about it really.
Post by: kitz on January 17, 2018, 09:01:38 PM
Quote
The obsolete models were the Draytek 2750 and 2850 which used a Metanoia VDSL2 chipset, not Lantiq.
Thank you I couldnt recall the numbers, although I did say "non Lantiq and BCM chipset based modems eg". Again I cant recall model nos but iirc some of the others were MediaTech?
Quote
That sounds very unlikely to me. I thought all the logic of selecting what profile to use was done by some part of the DLM, and then the DSLAM in the cabinet simply does what it's told regarding enabling G.INP in whichever direction(s) on a particular line.
Thats the theory, but theres some oddness that goes on if the modem isnt capable of G.INP.
As it currently stands on Huawei cabs g.inp only goes on for upstream on those modems capable of doing so. Yet it can still apply g.inp and INP for those that are capable.
It wasn't until in a live situation that Openreach saw the [unexpected] effects that trying to apply g.inp to modems that couldnt do so that they changed things and came out with G.INP Mk2.
How is DLM able to totally turn off G.INP for those ASUS modems, yet within quite a short timeframe (~2 weeks) then go back to using G.INP when a modem capable of re-tx is put back on the line. If it was just DLM then you would fully expect g.inp to go back on the line immediately a compatible router is put on the line.
Right from the very start and before re-tx went live, we were told non g.inp modems would not sync, yet on the Huaweis they still did. It wasn't until they applied re-tx to the ECI's that we started seeing the non-sync and sync instability problems.
The ECI's seem less capable of handling non compliant modems. Which is why I said I wonder if this is why they totally turned off upstream g.inp for the ECIs from the very start... knowing full well that the ECI modems and HH5As wouldnt work for upstream. In theory the ECI DSLAMs should be able to handle upstream.
In theory the ECI modems should be... and are, just they never got around to updating f/w for some reason.
Quote
I think part of the problem originates from BT never enforcing any modem compatibility rules,
^This.
It also remains to be seen if they do ever take any action against those modems causing issues. So far they don't appear to have done so other than trying to find a fix at their end. Thus delaying the roll out for the rest of us.
I suspect there were probably far more modems than anticipated being non compliant. ASUS has quite a large following as do several other modem manufacturers who havent yet bothered to apply for MCT.
All the evidence suggests that it is a compatibility issue and one which has affected the ECI's far more than the Huaweis.
Post by: Chrysalis on January 17, 2018, 09:08:46 PM
you didnt mention any of these technical advances other then capacity in that sentence.
The system level vectoring you mentioned doesnt really apply to to the openreach ECI rollout as they didnt order ECI vectoring kit. So what were the technology advances that are present in the M41?
Post by: ejs on January 17, 2018, 09:25:04 PM
If it was just DLM then you would fully expect g.inp to go back on the line immediately a compatible router is put on the line.
I wouldn't. Like I wouldn't expect the DLM to immediately remove someone's banding after say a line fault had been fixed.
Post by: kitz on January 17, 2018, 10:38:31 PM
kitz it was a question hence the ? after capacity.
you didnt mention any of these technical advances other then capacity in that sentence.
Read again. I did not just type line card capacity, it just so happened that was mentioned first
At the time ECI cabs were considered superior :/ The line cards had more capacity and historically ECI had made some serious technological advances when it came to VDSL. Ironically vectoring! I know when I found out my new cab was an ECI several people said they were considered better than the Huaweis. ECI were known and respected by other Telco's outside of the UK.
Ok I typed VDSL when I should have typed DSL or telecoms, but I didn't realise you wanted me to type a full breakdown. They've been respected in Telecoms since 1961 in many other countries.
They were the
- First to market CWDM (http://www.kitz.co.uk/adsl/21cn_network.htm#WDM) (Wave Division Multiplexing for Backhaul) This was pretty major compared to FDM and why we can now have much larger & cheaper backhauls
- First to market optical rings.
- First to market SDH (Transportation Layer protocols used for 21CN networks)
- First to market System Level Vectoring
- Pioneers in DSM (I'm sure you know what that is - but for others its Dynamic Spectrum Management)
- .. and more if you go check out their site
Quote
The system level vectoring you mentioned doesnt really apply to to the openreach ECI rollout as they didnt order ECI vectoring kit. So what were the technology advances that are present in the M41?
Theyve been doing system level vectoring since 2009. If memory serves me right it was for one of the South American countries somewhere like Argentina or in that region.
As I said in that very same post quote
It could have perhaps been a different story if Openreach had gone with the V41's
Jeeze now I feel like some sort of marketing rep for ECI which was definitely not my intention.
All I was trying to say is that they have a good history behind them and were respected in the industry at what they do, so BT was not dumb for going with ECI based on their past history.
So something is stuffed up with g.inp, being on a ECI cab myself that would definitely benefit from it I'm not too chuffed either, but that would appear to be some sort of incompatibility issue with modems rather than with the DSLAMs.
Yes compared to Huawei it is now poor, because without g.inp, Openreach wont do xdB, yet again I could benefit from that. The fact that Openreach ordered M41s rather than V41's again isnt the fault of ECI.
Ironically the man in the street doesn't have a clue nor care about g.inp.
Post by: Chrysalis on January 17, 2018, 10:43:18 PM
I just feel broadcom is always the safest bet as they seem to always have the best compatibility with other modems, and the features that broadcom support are usually more reliably working.
I remember my days on ukonline who used conexant based dslams.
In turn this utilised a feature called SRA which conexant supported, it worked really well with conexant modems, but had massive compatibility issues, I dont think there was a single success story with a single non conexant modem, and even newer conexant modems were not fully compatible so it had to be same generation of chipsets as well as same vendor.
Yet with broadcom devices, features seem much more universally reliable across different vendors and across different generations of broadcom chipsets. I suspect its because pre launch testing likely includes testing against broadcom dslams.
Post by: kitz on January 17, 2018, 10:49:22 PM
I wouldn't. Like I wouldn't expect the DLM to immediately remove someone's banding after say a line fault had been fixed.
If DLM has decided line needs action (for Huawei) then first thing it does is apply re-tx and apply that profile. With the ASUS it doesn't & it goes to INP and takes a couple of weeks to remove.
When we had g.inp mk1, if the modem couldn't do upstream g.inp, then it applied it as a ridiculously high level of INP which affected both upstream and downstream. Yet if the EU switched from say HH5A to HH5B then immediately they got G.INP when they plugged in the other modem. This was repeated time and time again... because the actual line profile was re-tx.
Post by: kitz on January 17, 2018, 11:03:30 PM
I just feel broadcom is always the safest bet as they seem to always have the best compatibility with other modems, and the features that broadcom support are usually more reliably working.
/snip/
Yet with broadcom devices, features seem much more universally reliable across different vendors and across different generations of broadcom chipsets. I suspect its because pre launch testing likely includes testing against broadcom dslams.
I must admit broadcom is my choice too, just because their chipsets have always worked best on my line. Even some of the old Speedtouch 585 modems which many hated, yet loved by those in the 24Mbps club with BE*
There has been one other modem that I really liked and that was the Solwise SAR110 which at the time (15yrs ago) was really quite good for the money and had some advanced features that no other router at the time did. Under the hood it was Globespan Virata. They were also in a few other modems such as the BT Voyager 205 & the Huawei MT882 that used same chip.
Generally speaking the BCMs do tend to do well on most lines and tend to give good performance. Things can change a little though on very long lines or lines getting lots of errors.. then some of the other modems may work better. The 2 wires were a good example of this.. they were brilliant for long lines, but garbage for short lines.
Post by: smallal on January 18, 2018, 10:38:13 AM
Post by: skyeci on January 18, 2018, 10:42:19 AM
Post by: S.Stephenson on January 18, 2018, 11:56:04 PM
Post by: smallal on January 22, 2018, 11:03:54 AM
Post by: Chrysalis on January 23, 2018, 10:12:39 AM
This leads me to speculate one of 2 scenarios.
1 - g.inp works well on ECI providing its not enabled on many ports, perhaps a cpu utilisation issue, I dont think this is the case, g.inp shouldnt need much processing power compared to say vectoring.
2 - there is compatibility issues as has been reported but BT retail decided they would deal with those issues and reported to openreach as such, which led to the situation we have now, but not for their entire customer base, just for their iptv customers. This seems the most plausible.
3rd possible situation.
3 - openreach have it enabled for all isp's that use iptv services, the accounts flagged could be the ones set to use the iptv qos flag on the cabinet to exchange backhaul. Is there other isp's iptv customers that have g.inp enabled which would suggest this is the case?
Post by: smallal on February 07, 2018, 10:29:26 PM
Post by: ktz392837 on February 08, 2018, 01:07:26 PM
Post by: rpdmallett on February 09, 2018, 08:42:51 PM
"UPDATE 1st Feb 2018
We understand that so far the ECI Retransmission Trial has migrated around 600,000 lines and the official rollout is about to commence across their estate. The xdB (3dB profile) has also been successfully applied to some ECI lines."
https://www.ispreview.co.uk/index.php/2017/12/openreach-pause-uk-trial-g-inp-fix-eci-fttc-broadband-cabs.html (https://www.ispreview.co.uk/index.php/2017/12/openreach-pause-uk-trial-g-inp-fix-eci-fttc-broadband-cabs.html)
So that's good news!
Post by: Ixel on February 09, 2018, 09:07:14 PM
Sorry if this is already posted elsewhere, but the ISPreview page has been updated:
"UPDATE 1st Feb 2018
We understand that so far the ECI Retransmission Trial has migrated around 600,000 lines and the official rollout is about to commence across their estate. The xdB (3dB profile) has also been successfully applied to some ECI lines."
https://www.ispreview.co.uk/index.php/2017/12/openreach-pause-uk-trial-g-inp-fix-eci-fttc-broadband-cabs.html (https://www.ispreview.co.uk/index.php/2017/12/openreach-pause-uk-trial-g-inp-fix-eci-fttc-broadband-cabs.html)
So that's good news!
YES! Hoorah, no more ECI DSLAM's living in the dark ages. I can't wait. I assume it'll take several weeks to roll it out to most of the DSLAM's? Then again it also depends when they start the official rollout, "about to commence" could still mean a few months away.
Post by: Chrysalis on February 10, 2018, 05:15:12 AM
Post by: ktz392837 on February 10, 2018, 05:44:13 AM
I have to say I am flabagasted especially regarding 3db and hope that rollout will start sooner rather than later :)
Post by: j0hn on February 10, 2018, 06:09:09 AM
Quote
I assume it'll take several weeks to roll it out to most of the DSLAM's?The retransmission rollout to Huawei cabinets was done at a rate of circa 45k lines per night.
When the full ECI rollout starts it will likely be at a similar rate.
My line isn't good enough to keep fastpath. When on ECI I was always interleaved. The difference between my line being interleaved and having G.INP @ 3dB snrm is 36Mb (interleaved) to 50Mb (G.INP 3dB).
Really happy for everyone on ECI that this finally seems to be happening.
Post by: banger on February 10, 2018, 06:12:38 AM
Post by: skyeci on February 10, 2018, 06:39:04 AM
fingers crossed the fix actually works.
Post by: broadstairs on February 10, 2018, 08:20:38 AM
Stuart
Post by: Ronski on February 10, 2018, 09:28:34 AM
Post by: Terranova667 on February 11, 2018, 08:29:24 PM
I'm still unsure if the Openreach ECI modem i'm using has been updated to work with G.INP as it's locked down i have no way of knowing, there hasn't been any Modem resets that would indicate a firmware update unless it happens before they enable the cab ?, will have to see how it goes when it happens whenever that maybe. :fingers:
Post by: Chrysalis on February 12, 2018, 12:58:18 AM
Right now about 5.6-5.7db at 79987 at 200-300 ES/day on fast path.
Post by: DMZ on February 12, 2018, 08:37:49 AM
This is good news. And I'm happy things are on the road to recovery at last for us on ECI cabinets.
How does the process work for both, is it in stages or all in one go?
I'm still learning bits and bobs.
Post by: burakkucat on February 12, 2018, 04:29:03 PM
How does the process work for both, is it in stages or all in one go?
I would imagine that G.998.4 (informally referred to as G.Inp) would first be enabled, then a stepwise reduction of the target SNRM would be applied -- checking the circuit's stability at each step.
Post by: DMZ on February 13, 2018, 11:05:45 AM
I would imagine that G.998.4 (informally referred to as G.Inp) would first be enabled, then a stepwise reduction of the target SNRM would be applied -- checking the circuit's stability at each step.
Thank you for the explanation. I'll keep an eye out on my and others experiences with it then.
Hopefully all goes well for everyone. :)
Post by: smallal on February 13, 2018, 02:41:06 PM
Post by: smallal on February 14, 2018, 05:52:32 PM
Old stats were: Max. down 74615 - actual 73445 - S/N 6.3db
Today's new stats: Max. down 78889 - actual 73997 - S/N 9db
Now all it needs is for the DLM to get it's finger out and tweak the speed up & the target S/N down.
Pity they didn't do a DLM reset automatically so as to speed the improvement up.
Post by: skyeci on February 14, 2018, 06:15:31 PM
Could be that G.INP was activated around 05:30 this morning on my line as it reset itself for the first time in months.
Old stats were: Max. down 74615 - actual 73445 - S/N 6.3db
Today's new stats: Max. down 78889 - actual 73997 - S/N 9db
Now all it needs is for the DLM to get it's finger out and tweak the speed up & the target S/N down.
Pity they didn't do a DLM reset automatically so as to speed the improvement up.
can you provide any more detailed modem stats?
Post by: smallal on February 14, 2018, 08:08:57 PM
This is the sum total of the DSL stats menu: (pathetic isn't it, many people have requested TP-Link to reinstate the full stats menu on the new VR series, but nothing yet)
DSL Modulation Type: VDSL2
Annex Type: Annex A/L
Upstream Downstream
Current Rate (kbps) 20000 73997
Max Rate (kbps) 29484 78999
SNR Margin (dB) 12.3 9.0
Line Attenuation (dB) 8.5 3.2
Errors (pkts) 19 5
Post by: skyeci on February 14, 2018, 08:37:42 PM
Post by: ejs on February 14, 2018, 08:40:35 PM
Post by: skyeci on February 14, 2018, 08:46:47 PM
Post by: GaryW on February 20, 2018, 09:52:33 AM
Any confirmed sightings?
Post by: skyeci on February 20, 2018, 10:07:52 AM
love to know where these supposed 600,000 lines are
Post by: j0hn on February 20, 2018, 10:38:40 AM
Before the Winter break they wrote..
Quote
UPDATE 1:53pm
We understand that this pause is temporary and will last until sometime in early 2018, which is largely attributed to the Christmas and New Year break.
In other words the trial should continue and Openreach are currently examining the initial rollout to 30,000 lines.
Then, magically....
Quote
UPDATE 1st Feb 2018
We understand that so far the ECI Retransmission Trial has migrated around 600,000 lines and the official rollout is about to commence across their estate.
How can they go in to the break with 30,000 and get ready to start back up with 600,000.
Sounds like Andy had been banding figures about to me :whistle:
A few of us should get an email as soon as a new ECI line gets G.INP on MyDSLWebStats.
It will be posted here within hours of that.
Post by: ktz392837 on February 20, 2018, 11:45:30 AM
Post by: DMZ on February 20, 2018, 11:56:53 AM
The only difference I seen was my max attainables increased.
I'm only brining this up as according to the G.INP article on this site it states about a short downtime for approximately 5 minutes whilst the firmware is updated. And that's stage 1.
Maybe I'm wrong and I had a different event occur. Just thought I'd share anyway.
Post by: Ixel on February 20, 2018, 12:49:56 PM
I believe last Thursday my cabinet had its firmware updated as it was down for about 6 minutes. This happened approximately at 9AM.
The only difference I seen was my max attainables increased.
I'm only brining this up as according to the G.INP article on this site it states about a short downtime for approximately 5 minutes whilst the firmware is updated. And that's stage 1.
Maybe I'm wrong and I had a different event occur. Just thought I'd share anyway.
Just out of curiosity what's the firmware version on the line card you're connected to now?
Post by: ktz392837 on February 20, 2018, 12:58:57 PM
Mine says 0xb206 (assuming I am looking at the correct stat) and has for as long as I remember so not sure if revision is a useful indicator unless you have 207 or something?
Thanks
Post by: stevebrass on February 20, 2018, 01:17:39 PM
Post by: DMZ on February 20, 2018, 01:18:37 PM
But from what I remember I saw the connection uptime was only 8 minutes and I checked the router logs to see it was down for 6 minutes prior. The only thing as stated that stood out to me was the max attainables increased. Speed wise, latency etc. everything was and is the same.
I assume it's the same process as described in the G.INP article as the downtime was similar. This is the first time it was down for so long.
Since it could be the case I would probably have to wait for some time for G.INP to be active going by how it worked on the Huawei cabinets.
Post by: kitz on February 20, 2018, 01:36:41 PM
I'm not certain if the line card f/w version makes any difference to g.inp as there were different versions last time g.inp was rolled out.
If its a DSLAM configuration update for something such as DLM then it may not show up on the line card version.
iirc mine has been IFTN:0xb206 for years. However I note it now says
Quote
IFTN:0xb206 (178.6) / v0xb206
I can't recall seeing the 178.6 before. :-\
Post by: Ixel on February 20, 2018, 01:44:51 PM
I'm moving house in a few weeks so I'll see what the new address is connected to and post it here. It will also be ECI, sadly.
Post by: roseway on February 20, 2018, 01:47:36 PM
Quote
I can't recall seeing the 178.6 before
Sorry for the confusion. The numbers 178 and 6 are just the decimal equivalents of the hexadecimal values b2 and 06. A user requested that I add this conversion in the stats. Nothing has changed in your cabinet.
(I made this change in version 6.1.1 which hasn't been generally released yet.)
Post by: kitz on February 20, 2018, 01:53:34 PM
Sorry for the confusion. The numbers 178 and 6 are just the decimal equivalents of the hexadecimal values b2 and 06. A user requested that I add this conversion in the stats. Nothing has changed in your cabinet.
(I made this change in version 6.1.1 which hasn't been generally released yet.)
Thank you Eric for the explanation. I am indeed using 6.1.1 :)
Post by: jaydub on February 20, 2018, 02:24:59 PM
ChipSet Vendor Id: IFTN:0xb206
Post by: skyeci on February 20, 2018, 02:27:39 PM
Post by: wj66 on February 20, 2018, 03:05:46 PM
Post by: j0hn on February 20, 2018, 03:16:21 PM
I believe last Thursday my cabinet had its firmware updated as it was down for about 6 minutes. This happened approximately at 9AM.I see nothing in what you describe that would suggest the cabs firmware was updated. Likely just the DSLAM being rebooted or a dozen other possibilities.
The only difference I seen was my max attainables increased.
I'm only brining this up as according to the G.INP article on this site it states about a short downtime for approximately 5 minutes whilst the firmware is updated. And that's stage 1.
Maybe I'm wrong and I had a different event occur. Just thought I'd share anyway.
Without any further info from OpenReach and going by previous rollouts I wouldn't be surprised if any full rollout of g.inp was held back a little till late March/April.
MDWS has a nice scattering of users all over the country. When it comes, we'll see it.
Post by: j0hn on February 20, 2018, 03:21:19 PM
Mine was 0xb206 on the old line at my current address, and 0xd086 on the new line (from AAISP) at my current address.These are the only 2 firmwares I've seen on ECI (since 0xb204 was updated?).
0xd086 seems to be much less common. It was very interesting to see when your 2nd line went live that both linecards had different firmwares. I'm curious as to the significance of this.
Post by: S.Stephenson on February 20, 2018, 05:09:39 PM
It'll go live the week after I get it obviously.
Post by: skyeci on February 20, 2018, 05:18:43 PM
I'm hoping to get it first again :P
It'll go live the week after I get it obviously.
lol.. ;D pigs might fly first :D
Post by: Ornum on February 22, 2018, 04:48:05 PM
Post by: j0hn on February 22, 2018, 05:09:39 PM
Post by: Chrysalis on February 24, 2018, 06:29:07 AM
Post by: GaryW on February 24, 2018, 12:12:11 PM
Wait till march 4th week.
Beware the INPs of March? :)
But seriously, is there a specific reason you mention that week?
Post by: underzone on February 24, 2018, 12:30:05 PM
Take it as gospel... :)
Post by: MrMike on February 24, 2018, 08:42:54 PM
Post by: Zico on February 24, 2018, 10:20:13 PM
Post by: j0hn on February 24, 2018, 10:41:20 PM
Lower snrm targets are done on an individual line basis.
A lower target SNRM basically allows more bits per tone to be used. M is Margin, or tolerance/threshold level.
If you look at my attached screenshot you can see the purple line (SNR per tone) above the bits.
In plain English, a lower SNR Margin increases the threshold at what tones are useable.
With a 6dB target SNRM all the tones on my line in U2 and D3 are unusable and empty.
My line is currently on a 3dB target SNRM.
Post by: smallal on March 05, 2018, 12:10:55 AM
Could be that G.INP was activated around 05:30 this morning on my line as it reset itself for the first time in months.Looks like G.INP wasn't activated, but probably a firmware update to the CAB (as reported elsewhere) was.
Old stats were: Max. down 74615 - actual 73445 - S/N 6.3db
Today's new stats: Max. down 78889 - actual 73997 - S/N 9db
Now all it needs is for the DLM to get it's finger out and tweak the speed up & the target S/N down.
Pity they didn't do a DLM reset automatically so as to speed the improvement up.
My improvement lasted a few days before the DLM had a total meltdown.
The max speed went up again by over 10mbps but the actual connection speed dropped like a stone to below 60mbps, with nightly resyncs (between 5 & 6am) just making things worse.
A call to BT resulted in an engineer callout, he tried 2 DLM resets but then gave up, then he did a lift & shift which sorted the problem.
Since the I'm stable, up time is over 9 days, no nightly resyncs and an acceptable speed.
Upstream Downstream
Current Rate (kbps) 20000 77186
Max Rate (kbps) 29553 78363
SNR Margin (dB) 12.2 6.3
Line Atten (dB) 8.5 3.1
Still an improvement on my old connection speeds so worth the effort I suppose.
Let's see what happens later this month, if G.INP does get turned on again, will I get my old 80mbps profile back (after 2+ years)?
Post by: smallal on March 07, 2018, 04:29:50 PM
Which will be live first - G.FAST or G.INP!
Post by: MrMike on March 07, 2018, 06:19:37 PM
Post by: burakkucat on March 07, 2018, 07:54:25 PM
The race is on! A G.FAST pod was bolted onto the side of my local street cabinet cabinet today.
Which will be live first - G.FAST or G.INP!
G.998.4 (a.k.a. G.Inp) is a mandatory requirement for G.9700/G.9701 (a.k.a. G.Fast). :)
Post by: ejs on March 07, 2018, 08:12:55 PM
Post by: Ronski on March 07, 2018, 10:07:14 PM
G.998.4 (a.k.a. G.Inp) is a mandatory requirement for G.9700/G.9701 (a.k.a. G.Fast). :)
Not sure if BC is a little sleepy but I believe he was referring to g.inp on the ECI cabinet.
Post by: smallal on March 07, 2018, 10:37:11 PM
BT/Openreach haven't really given out much information since the 'pilot extension' announcement at the end of last year, but my exchange wasn't on the list.
Post by: burakkucat on March 07, 2018, 11:03:42 PM
Strictly speaking, retransmission is an integral part of G.9701. It may well have been based on the scheme defined in G.998.4 (G.INP), but it is not actually G.998.4.
Thank you.
Not sure if BC is a little sleepy but I believe he was referring to g.inp on the ECI cabinet.
:sleep:
Post by: rbgb on March 09, 2018, 07:57:55 AM
Post by: Ronski on March 09, 2018, 08:01:54 AM
ETA. It appears the user may be on Huawei cabinet.
Post by: skyeci on March 09, 2018, 08:10:08 AM
I’m on an ECI cabinet in West London and had g.imp enabled on the downstream yesterday for the first time (9th March) so looks like the role out is happening now.
according to mdws you are on huawei if you are the same user as your username here?
Could we see some modem stats please to confirm cab type please
thanks
Post by: j0hn on March 09, 2018, 10:48:47 AM
I’m on an ECI cabinet in West London and had g.imp enabled on the downstream yesterday for the first time (9th March) so looks like the role out is happening now.Your Interleave depth is 8.
Unless they changed how ECI did G.INP and forgot to tell ayeaye and Semmy's lines, looks like you're on a Huawei cabinet?
edit: There's no tone data on MDWS so can't tell for certain the cab type. Would be interested to see the Stats tab from DslStats.
Quote from: DslStats Stats tab
Stats recorded 09 Mar 2018 11:00:07
DSLAM/MSAN type: BDCM:0xa48c / v0xa48c
Modem/router firmware: AnnexA version - A2pv6F039v.d26a
DSL mode: VDSL2 Profile 17a
Status: Showtime
Post by: smallal on March 23, 2018, 10:51:45 AM
Wait till march 4th week.If this prediction for action on G.INP is accurate it would be next week.
Would they risk 'going live' with this so close to easter?
Post by: ktz392837 on March 23, 2018, 12:52:40 PM
I am hoping the forum users who get to know more information will then be able to post an update if an update is made by BT?
Post by: skyeci on March 23, 2018, 02:10:29 PM
I not convinced we will see it all. the last email I had from open reach was suggesting several months if at all so perhaps it's just a myth.. :-\
hope I am wrong but it seems to have gone on and on and on..
Post by: ejs on March 23, 2018, 05:16:19 PM
It's gone on for so long that I've even recently managed to read the original Openreach briefings from 2016, only the last one has any real content and its content had already been relayed to us.
Post by: Ixel on March 28, 2018, 10:51:34 AM
Post by: kitz on March 28, 2018, 11:07:00 AM
No guarantee that its g.inp related. There's a couple of briefings which could indicate they are also making some DLM changes.
I was hoping that G.INP would be applied to ECI cabs before they start rolling out Error Correction on all new lines by default but who knows now with G.INP appearing to have been delayed yet again.
Post by: Ronski on March 28, 2018, 01:29:22 PM
Post by: shadow4dog on March 28, 2018, 03:17:13 PM
I also had a resync a few days ago, still on fast path, haven't checked anything else.And me too. Both my Zen (BT Wholesale) and Sky VDSL lines went down at 2am last Thursday. I mistakenly thought it was G.Inp because I got an extra 2Mb/s actual sync speed per line! But, like most places, our street suffers badly from crosstalk.
Tim
Post by: smallal on March 28, 2018, 05:42:17 PM
The street cabinet now has an extension pod on one side & a G.Fast pod on the other.
Added to that there's a new HUGE fibre cab right next to it.
Not sure if they'll decommission the old (much smaller) ECI box currently about 60metres away.
If they migrate the lines to the new box then happy days, otherwise it's G.FAST when it goes live.
I live in hope of G.INP returning, but all remains silent since they suspended trials at the end of last year.
Post by: j0hn on March 28, 2018, 05:50:59 PM
Quote
Not sure if they'll decommission the old (much smaller) ECI box currently about 60metres away.
If they migrate the lines to the new box then happy days, otherwise it's G.FAST when it goes live.
I live in hope of G.INP returning, but all remains silent since they suspended trials at the end of last year.
That's extremely wishful thinking.
I've never known them to decommission an ECI cabinet after installing a Huawei.
The new larger cabinet is most likely to add capacity. Removing the ECI would have the opposite effect.
OpenReach get the same revenue from customers for either cabinet vendor.
Even if G.INP was never fixed on ECI cabinets they wouldn't be swapped.
At least you have 3 options.
You could order a 2nd line once the new cab goes live, then cancel the 1st line.
You could take up G.Fast if you're close enough.
You could wait it out and hope they fix G.INP on the ECI's.
Post by: smallal on April 05, 2018, 09:36:35 PM
Chrysalis has a Kitz verified 'inside source'.Big news in the 4th week in March, its gospel.
Take it as gospel... :)
And the good book said nothing.
Just as well I'm not religious.
Post by: burakkucat on April 05, 2018, 09:49:17 PM
Big news in the 4th week in March, its gospel.
And the good book said nothing.
Just as well I'm not religious.
The latest update can be found here (http://forum.kitz.co.uk/index.php/topic,21320.0.html). (And it's not good news. :( )