Retraction of G.INP :(

So I read a few rumours that G.INP is going to be disabled on upstream for all lines now!

That's both Huawei and ECI cabinets!

I don't think this is very good and is a great example of our providers making a boo boo and passing the ramification's on too the service users...

Why is it that ISP's and Openreach haven't been held responsible for any issues that have been caused during this "boo boo" after all it was their engineers/contractors and departments that sent/installed the wrong EU Equipment in the first place.

In reply to a post by mlmclaren:

So I read a few rumours that G.INP is going to be disabled on upstream for all lines now!

Meh. Very few people need it so it seems a reasonable solution to me.

Why is it that ISP's and Openreach haven't been held responsible for any issues that have been caused during this "boo boo" after all it was their engineers/contractors and departments that sent/installed the wrong EU Equipment in the first place.

Because they provide a service and by the standards of the industry they are doing a reasonable job which is all they are required to do. If you think you can roll-out FTTC (or indeed any other communications technology) across the UK and get it right for everyone first time then set up your own company and go into business.

Anyway upstream G.INP really isn't worth crying about. I think it's far better they concentrate their R&D efforts on the next gen upgrades than tweak a pretty minor feature of the current system.

Edited by Andrue (Sat 06-Jun-15 15:50:49)

In reply to a post by Andrue:

In reply to a post by mlmclaren:

So I read a few rumours that G.INP is going to be disabled on upstream for all lines now!

Meh. Very few people need it so it seems a reasonable solution to me.

A lot more people need it than would otherwise have been the case due to the use of contractors .

Also it's a poor compromise because the largest customer - BT Consumer - supplied the wrong sort of Homehub - HH5A's - to customers on Huawei cabinets.

So, it is needed because of bad installs but no-one can have it because of the uncontrolled issue of free Homehubs.

In reply to a post by BatBoy:

In reply to a post by Andrue:

In reply to a post by mlmclaren:

So I read a few rumours that G.INP is going to be disabled on upstream for all lines now!

Meh. Very few people need it so it seems a reasonable solution to me.

A lot more people need it than would otherwise have been the case due to the use of contractors

What's the contractor connection?

Edited by Andrue (Sat 06-Jun-15 18:24:36)

Poor installs (and supplying ECI modems and selling the Huaweis on Ebay)

If you suspect an ebay aeller is selling stolen goods then am sure BT security would like to know

I think the volume of Huawei HG612s for sale on Ebay over the last 4 years speaks for itself.

Handing out ECI modems to subscribers might well cause a contractor's van to become relatively top-heavy with HG612's.

However, that inventory doesn't suddenly get labelled as "spare", and free for a contractor to dispose of. He still has to do something fraudulent to be able to sell them.

In reply to a post by BatBoy:

In reply to a post by Andrue:

In reply to a post by mlmclaren:

So I read a few rumours that G.INP is going to be disabled on upstream for all lines now!

Meh. Very few people need it so it seems a reasonable solution to me.

A lot more people need it than would otherwise have been the case due to the use of contractors .

Also it's a poor compromise because the largest customer - BT Consumer - supplied the wrong sort of Homehub - HH5A's - to customers on Huawei cabinets.

So, it is needed because of bad installs but no-one can have it because of the uncontrolled issue of free Homehubs.

I have to say that I disagree there.

Upstream problems have never been worse than downstream ones. DLM becomes involved considerably less on the upstream side.

And the *impact* of packet loss on upstream is felt even less: The main issue that BT wants to solve with G.INP (loss of packets that don't otherwise get retransmitted - particularly in video streaming) just doesn't happen upstream.

Don't get me totally wrong though ... a solution that kept G.INP bi-directional would be an improvement, as would deployment of capable hardware. It's just that turning G.INP off upstream isn't as terrible as you make it sound.

BTW. As far as I can see, the issue isn't as simple as hardware that doesn't support G.INP upstream. Some modems, using the same "limited" chipsets, have been "fixed" by firmware upgrade. If the issue remains long-term for some models, then something more subtle has gone wrong.

I have plenty of experience of capped upstream speeds following ham fisted installers visiting my cabinet, so don't try and tell me it doesn't happen. G.INP managed to fix that for a brief couple of months.

Well this has become a bit of a busy thread... anyway onwards to my reply...

In reply to a post by Andrue:

Meh. Very few people need it so it seems a reasonable solution to me.

Because they provide a service and by the standards of the industry they are doing a reasonable job which is all they are required to do. If you think you can roll-out FTTC (or indeed any other communications technology) across the UK and get it right for everyone first time then set up your own company and go into business.

Anyway upstream G.INP really isn't worth crying about. I think it's far better they concentrate their R&D efforts on the next gen upgrades than tweak a pretty minor feature of the current system.

The fact as already pointed out is that a lot of people where finding improvements with the G.INP implementation on the Huawei cabinets and yes it has improved mine and other users upstream... many users who have had their upstream interleaved due to line condition issues or noise see a lesser throughput than someone with fast path or a G.INP enabled line... G.INP also reduce's errors on the line in both directions...

But to be fair to Openreach, they can get away with these shoddy practice's because they have people like yourself who will excuse their "substandard" procedures...

PS. If I was to roll out a Superfast / Next Generation Broadband Infrastructure across the UK I would do it correctly the first time.... because I would do it properly.... not quick and on the cheap... and I wouldn't have different equipment in different area's and if mine did I would certainly have a system in place to prevent the use of incompatible equipment or even the activation of the wrong equipment upon a service installation!

In reply to a post by mlmclaren:

PS. If I was to roll out a Superfast / Next Generation Broadband Infrastructure across the UK I would do it correctly the first time.... because I would do it properly.... not quick and on the cheap

And where would you get the money for that? If I remember correctly the estimates to provide FTTP to the entire UK were around £30 billion ten years ago. But yes, your strategy would not be quick. Instead of 90% having a significant improvement by 2013 only a small handful would have had an improvement by now. Most of the country would still be stuck on ADSL with little likelihood of anything better this decade.

There's a reason why BT went the route they did. It was all that they could afford to do and the only way to get significant improvements out in a half-way reasonable timescale. BT have to operate in the real world whereas you obviously don't.

There is also going to be a good reason why BT are adopting the solution they have with respect to G.INP. Yes, it's a kludge. It's not ideal. But as a (software) engineer with over 30 years experience I can tell you that waiting for the perfect solution means never getting the job done. In the commercial world you often have to accept 'good enough'. G.INP matters quite a lot for quite a lot of lines in the downstream. It matters not a greal deal to only a few lines in the upstream.

Edited by Andrue (Sun 07-Jun-15 09:22:27)

In reply to a post by BatBoy:

I have plenty of experience of capped upstream speeds following ham fisted installers visiting my cabinet, so don't try and tell me it doesn't happen. G.INP managed to fix that for a brief couple of months.

We're not saying it doesn't happen but one person getting into a hissy fit over a dodgy install really isn't very significant. Not even if it's you (sorry - this is that pesky real world again that I mentioned in my other response).

If you think there's a fault with your line then get an engineer out.

There are many reasons for not getting an engineer out, including:

BT don't guarantee upstream speeds
BT will find the line speeds are within spec
BT will charge £130
BT will tell me to reboot the router several times
BT will tell me to change the wireless channel
BT will say the problem is due to the number of devices connected

Whereas G.INP just fixes it automatically.

I have to wonder who the "we" are

So make the complaint official, and eBay does take action when stolen goods are listed

What would that achieve?

Well might make you happier, and stop the sellers who are selling stolen goods as you allege

I want G.INP back on the upstream, which has been turned off due to problems with ECI modems and HH5A's that have been supplied to customers on Huawei cabinets.

Complaining to Ebay and/or BT Security appears to be rearranging the deckchairs on the Titanic. What's the point?

Stops others getting the poor installs you complained about

In reply to a post by MrSaffron:

Stops others getting the poor installs you complained about

I don't think it would. All it would do is stop people buying a Huawei HG612 and so stop them fixing their connection themselves.

What we need is G.INP turned on for everyone whose equipment supports it on the upstream.

In reply to a post by BatBoy:

In reply to a post by MrSaffron:

Stops others getting the poor installs you complained about

I don't think it would. All it would do is stop people buying a Huawei HG612 and so stop them fixing their connection themselves.

What we need is G.INP turned on for everyone whose equipment supports it on the upstream.

I have to wonder who the "we" are

So about £600 per adult in the UK.
If you say give first year BB for free.

I'd go for that..

That's precisely why they don't go for it.

The solution is simple but not cheap... a recall of incompatible equipment for replacement with capable equipment.

and new rules on 3rd party equipment... so those with 3rd party equipment that shares similarities with capable BTO equipment can have G.INP assigned by DLM but anyone using equipment with say chipsets other than Broadcom will be stuck on standard Fast path or interleaved profiles even if their chipset supports G.INP on downstream or upstream..

or better still, ban incompatible chipsets from connection to the DSLAM and those with 3rd party equipment will be told they must switch back to a HG612 (if they had one originally) or will be issued a replacement for an ECI modem!

Those who no longer have their HG612's will obviously then have to find an alternative method as it does belong to Openreach and passing it on is "supposed" to be theft!

Edited by mlmclaren (Sun 07-Jun-15 14:31:21)

In reply to a post by mlmclaren:

Those who no longer have their HG612's will obviously then have to find an alternative method as it does belong to Openreach and passing it on is "supposed" to be theft!

This is not true, I checked.

Really?? Oh OK!

I was lead to beleive they had the same status as the master socket and also aren't they supposed to be left where installed... so no ring them between properties?

This still doesn't excuse anything mentioned above though...

Open reach will still thrown upon those who have removed equipment installed and approved by themselves and "shouldn't" cover users that have removed equipment and replaced it with 3rd party equipment...

Just like if we had issues that where found to be the router beyond the modem..

In reply to a post by mlmclaren:

The solution is simple but not cheap... a recall of incompatible equipment for replacement with capable equipment.

But a lot of those modems were installed before G.INP was enabled. They were fully compatible with the service at the time they were installed. What you're suggesting here is that you want to punish BT for improving their service.

or better still, ban incompatible chipsets from connection to the DSLAM and those with 3rd party equipment will be told they must switch back to a HG612 (if they had one originally) or will be issued a replacement for an ECI modem!

So you're not a fan of freedom of choice then? Tell you what - why don't we just roll the clock back and say no-one can fit any telephony equipment to a BT line unless BT have supplied it. Except that, of course, this whole issue is the result of using BT supplied equipment.

Edited by Andrue (Sun 07-Jun-15 20:55:17)

The problem is wholly down to BT. They created it, they should fix it, not fudge it.

In reply to a post by BatBoy:

The problem is wholly down to BT. They created it, they should fix it, not fudge it.

But they have fixed it. They've disabled G.INP in the upstream. That solves the problem and means no-one is worse off than they were before G,INP was introduced. That that some modems can't take full advantage of a new feature is irrelevant.

Edited by Andrue (Sun 07-Jun-15 20:58:51)

In reply to a post by Andrue:

What you're suggesting here is that you want to punish BT for improving their service.

Noooo...

BT where the one's that said that ECI modems shouldn't of been installed for use with Huawei DSLAM's even when they where compatible with each other...

In reference to www.thinkbroadband.com/news/6921-g-inp-roll-out-receives-mixed-reac...:

Openreach did express some surprise when we pointed out that people had at times being supplied with an ECI modem in a Huawei cabinet area when engineer installs were the norm.

BT improving there service is great but now they want to remove that improvement... or at least 50% of it and that to me is not good practice.

In reply to a post by Andrue:

In reply to a post by BatBoy:

The problem is wholly down to BT. They created it, they should fix it, not fudge it.

But they have fixed it. They've disabled G.INP in the upstream.

They fudged it.

In reply to a post by BatBoy:

In reply to a post by Andrue:

In reply to a post by BatBoy:

The problem is wholly down to BT. They created it, they should fix it, not fudge it.

But they have fixed it. They've disabled G.INP in the upstream.

They fudged it.

The problem no longer exists. That's a fix. An ugly fix, but it's a fix.

In reply to a post by Andrue:

In reply to a post by BatBoy:

The problem is wholly down to BT. They created it, they should fix it, not fudge it.

But they have fixed it. They've disabled G.INP in the upstream.

That's not fixing it... it's just preventing it...

Soi what your saying is a brand new infrastructure is already at it's limit and no further upgrades can now go ahead because BT might have to put their hands up and say

"were sorry we made a boo boo, we'll fix it"

Also G.INP was a fix for noise issues... so they have replaced a problem with another problem..

Only difference is they can stand behind the first problem and say that it's out of their hands!

They turned it on and it didn't work.
The fix is to make it work.
The fudge is to turn it off.

In reply to a post by mlmclaren:

In reply to a post by Andrue:

In reply to a post by BatBoy:

The problem is wholly down to BT. They created it, they should fix it, not fudge it.

But they have fixed it. They've disabled G.INP in the upstream.

That's not fixing it... it's just preventing it...

It's making a problem go away. Now you're no worse off than you were before G,INP was rolled out. Slightly better off in fact since you still have it on the downstream where it really matters.

Soi what your saying is a brand new infrastructure is already at it's limit and no further upgrades can now go ahead because BT might have to put their hands up and say

"were sorry we made a boo boo, we'll fix it"

I think that's already pretty obvious with their apparent abandoning of vectoring. This is why I'd like to see them stop tinkering about with VDSL. It's been a useful stop gap that got the country a lot further a lot faster than the alternatives but it's time they resurrected FTTPoD and this time with a sensible pricing structure. Trouble is they are already pratting about with G,FAST (which I think will never get beyond the trial stage). Their solutions often have these kind of issues, it's a downside of the way they operate.

Unfortunately I can't see any other way they can do it other than through technology increments. I just have my doubts that G.FAST is going to be appropriate for the next increment.

Edited by Andrue (Sun 07-Jun-15 21:11:39)

In reply to a post by mlmclaren:

Also G.INP was a fix for noise issues... so they have replaced a problem with another problem..

There is no 'other problem' any longer. They've turned that feature off. They haven't been able to implement as much of an upgrade as they'd hoped. That's all.

But making VDSL more stable should be there main priority currently...

You said it yourself there is a big funding gap to fill for fibre services and as G.INP was a big help as more and more people joined the infrastructure it's is a major requirement, even with G.INP on my line I've lost 2000kbps of downstream and upstream sync due to more and more people joining the cabinet..

So I do sit concerned of much upstream will be lost once G.INP is removed from my 288 line capable cab once it get's to 50% utilised nevermind higher.

In reply to a post by BatBoy:

They turned it on and it didn't work.
The fix is to make it work.
The fudge is to turn it off.

No. They turned it on and it caused a problem. They turned it off and the problem is no longer there. The upgrade was a partial failure but they have fixed the problem it caused.

Edited by Andrue (Sun 07-Jun-15 21:14:50)

In reply to a post by Andrue:

In reply to a post by mlmclaren:

Also G.INP was a fix for noise issues... so they have replaced a problem with another problem..

There is no 'other problem' any longer. They've turned that feature off. They haven't been able to implement as much of an upgrade as they'd hoped. That's all.

So they fixed crosstalk then....

I'll see you at the brick wall.... we can bang our heads against it together!

In reply to a post by Andrue:

They turned it on and it caused a problem. They turned it off and the problem is no longer there. The upgrade was a partial failure but they have fixed the problem it caused.

What we have at the moment is an understandable kludge, rather than a fix. Openreach enabled bidirectional G.INP and found that upstream G.INP caused problems on some lines. They should be able to identify these problematic lines, as they were the ones that negotiated high upstream interleaving rather than upstream G.INP. Hopefully a way will be found to return to bidirectional G.INP on those lines where both DSLAM and CPE are capable of it.

The counter-argument being that if the upstream problem due to any of the several causes had been discovered during testing, the introduction of downstream G.INP alone would have been greeted with the same enthusiasm as was the full but problematical version.

xDSL of any flavour is a kludge. Very useful it is too .

I agree, Bob - though we cannot ignore that the initial G.INP deployment was a wide area test of bidirectional G.INP which should not be ignored.

As you say, all DSL is a clever kludge. All I'm hoping for here is that once Openreach have proved that downstream only G.INP is a workable solution for the problems found in the initial deployment, they return to the original G.INP implementation but replace the problematic high depth upstream interleaving profiles for lines incapable of bidirectional G.INP with the current downstream G.INP only profiles.

In reference to community.bt.com/t5/BT-Infinity-Speed-Connection/G-INP-affecting-ce...:

How to Fix the ECI modem with G.INP!

Step 1: Place modem on a solid base. http://prntscr.com/7eid9w

Step 2: Hammer 8 nails in the top. http://prntscr.com/7eidx3

Step 3: Write with a highlighter G.INP on the front. http://prntscr.com/7eiedw

Step 4: Take a saw and cut half way down the modem. http://prntscr.com/7eieiq

Step 5: Take a hammer a smash the top until the lid comes apart. http://prntscr.com/7eiey6

Step 6: Completely remove the lid so you can see the chipset. http://prntscr.com/7eif9l

Step 7: Compliment your modem. http://prntscr.com/7eifjt

Final Step Optional. Recycle. http://prntscr.com/7eig53

In reply to a post by mlmclaren:

In reply to a post by Andrue:

In reply to a post by mlmclaren:

Also G.INP was a fix for noise issues... so they have replaced a problem with another problem..

There is no 'other problem' any longer. They've turned that feature off. They haven't been able to implement as much of an upgrade as they'd hoped. That's all.

So they fixed crosstalk then....

I see you're still confused then. You're treating all of this like one 'thing'. It isn't. There are two parts to it:

#1 G.INP - an upgrade intended to improve connection speed in the face of localised interference.
- This has been partially implemented. Or more accurately, fully implemented then part rolled back.
#2 G.INP interfering with upstream connection speeds. This has been fixed.

You're also miss-applying the term 'fix'. G.INP is not a fix for anything. It's an upgrade intended to improve connections in the face of line noise. For G.INP to 'fix' noise it would have to stop it happening. For vectoring to 'fix' crosstalk it would have to eliminate it.

Neither of these things is possible - all anyone can do is attempt to mitigate them. As RobertoS has posted - xDSL is a kludge from beginning to end. It always has been. About the only things that have been fixed are problems directly attributable to the technology. G.INP ruining the upstream for some modems is an example of that and it has now been fixed. Not in the best way but good enough for most people and hopefully without distracting BT's R&D teams away from more important things.

Edited by Andrue (Mon 08-Jun-15 16:40:31)

In reply to a post by David_W:

I agree, Bob - though we cannot ignore that the initial G.INP deployment was a wide area test of bidirectional G.INP which should not be ignored.

As you say, all DSL is a clever kludge. All I'm hoping for here is that once Openreach have proved that downstream only G.INP is a workable solution for the problems found in the initial deployment, they return to the original G.INP implementation but replace the problematic high depth upstream interleaving profiles for lines incapable of bidirectional G.INP with the current downstream G.INP only profiles.

It'd be nice but until I hear of widespread issues with upstream connection speeds (and all I've really heard is the opposite(*)) I'm just not going to worry about it. It's just possible of course that this is an interim fix. Perhaps they feel that the downstream issues are so important that they have to roll that out but as a temporary fix they have disabled the upstream G.INP and tweaked the interleaving. Maybe a better fix will be rolled out in a few months.

(*)Referring here of course to pre-G.INP complaints. I find it interesting that when G.INP actively interferes with upstream we get a tidal wave of complaints yet until then almost nothing had been said about upstream problems. That suggests that there never was a huge need for an upstream improvement.

Edited by Andrue (Mon 08-Jun-15 16:46:53)

You keep saying that removing G.INP is fixing a fault but it's not... it's merely reverting to an older fault...

Call it crosstalk, interference or whatever it was/is still improved using G.INP on both downstream and upstream...

I'm no longer going to discuss this with you because you are obviously going to continue praising Openreach for abandoning plans to improve users services and keep going on about FTTP/oD which as you said is many many many years away.

I did that to a SuperHub...

and probably would have do it to an ECI if I had one too... Luckily I used common sense and thought matching the chipset manufacturers,

And when the Openreach engineer brought an ECI modem in to connect my service I sent him back to his van to hunt a Huawei..

In reply to a post by David_W:

In reply to a post by Andrue:

They turned it on and it caused a problem. They turned it off and the problem is no longer there. The upgrade was a partial failure but they have fixed the problem it caused.

What we have at the moment is an understandable kludge, rather than a fix. Openreach enabled bidirectional G.INP and found that upstream G.INP caused problems on some lines. They should be able to identify these problematic lines, as they were the ones that negotiated high upstream interleaving rather than upstream G.INP. Hopefully a way will be found to return to bidirectional G.INP on those lines where both DSLAM and CPE are capable of it.

no it didn't cause problems on any line/circuit as such any problems where caused by the use of incompatible modems that where supplied by BT OR engineers or by BT consumer HH5version A
Compatible devices did not show the same problems BT should of recalled all of the incompatible devices it supplied and replaced them with fully compatible devices, end of
As for the ECI cabs that are incompatible with G.inp as well they need to upgrade them so they are compatible ,

Edited by tommy45 (Mon 08-Jun-15 21:12:57)

I agree, it should be BT Retail swapping A's for B's and ECI cabs should only have G.INP enabled on downstream if that's all they can handle...

I have a feeling that ECI modems might have better G.INP capability when used on ECI cabs but I'm assuming there will be Huawei's on ECI cab's also

In reply to a post by Andrue:

#1 G.INP - an upgrade intended to improve connection speed in the face of localised interference.
- This has been partially implemented. Or more accurately, fully implemented then part rolled back.
#2 G.INP interfering with upstream connection speeds. This has been fixed.

I look forward to you explaining how G.INP improves connection speed.

tommy - I was using "lines" as shorthand for "circuits where both DSLAM and CPE support bidirectional G.INP..

In reply to a post by mlmclaren:

The solution is simple but not cheap... a recall of incompatible equipment for replacement with capable equipment.

Perhaps we should nip this one in the bud. There is no such thing as incompatible equipment in this case.

Go back and look at SIN 498. There you'll find that support for G.INP in the upstream direction is optional (in the current version v6.0, dated Sept 2014)

or better still, ban incompatible chipsets from connection to the DSLAM and those with 3rd party equipment will be told they must switch back to a HG612 (if they had one originally) or will be issued a replacement for an ECI modem!

In the end, it looks like BT made the mistake of not properly coping, on the DSLAM or DLM side, with the case of an optional feature that the modem has validly choosen not to support.

The fix is borked , they still need to reduce the amount of FEC overheads so people get their full upstream sync speed back, IMO if equipment is capable of using G.inp bi directionally then they should allow that, For me they could revert my connection back to fast path and disable DLM all together as i don't want or need it

Edited by tommy45 (Tue 09-Jun-15 05:32:54)