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)