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..