In reply to a post by BatBoy:

In other news, the Tories will win the 2015 election.

Whatever....

I won't bother next time

Oh come on, I was joking - trust me.

In reply to a post by BatBoy:

Oh come on, I was joking - trust me.

You just don't know when to stop do you?

thanks for the info, I suspected it was coming as the ECI dslams are getting a new firmware (or card swap) rolled out.

Looks like the ECI configuration is different to hauwei in how its implemented.

Given you complained about losing a couple of hundred kilobits a second of downstream to the G.inp retransmit bearer perhaps better they keep it off.

BT aren't deploying vectoring on a national scale and have never suggested they would.

People are more likely to get FTTP or G.fast. Vectoring will go to a tiny subset of cabinets where it can push lines over 24 or 30Mb.

IIRC G.Fast employs vectoring by default doesn't it? At least the Openreach implementation.

It is an integral part of the G.Fast standard.

However, as some of the uses cases involve a G.Fast node with a single port, supporting a single line, there are some cases where vectoring isn't necessary and, I imagine, can be left out of the chipset for cost reasons.

Given we're discussing ECI VDSL cabinets I didn't see the point in complicating the issue in the name of pedantry.

G.fast requires vectoring. There are no implementations that don't have it.

G.INP wasn't on the radar when the fibre rollout started so the modems didn't have to support it. I think G.INP first appeared in SIN498 v5(?).

Sin 498 (v4.3) January 2013 Requirement R.VDSL2.10 for downstream PHY Layer retransmission reinstated.

Sin498 (v5) June 2013 Requirement R.VDSL2.10 for downstream PHY Layer retransmission made mandatory.

Therefore any CPE supplied since June 2013 should support G.INP but the HH5 type A doesn't.