It's unlikely to increase further if your noise margin is on target of 6.

In reply to a post by BatBoy:

It's unlikely to increase further if your noise margin is on target of 6.

My SNR margin is 6.3 down and 16.6 up. I've not gone in to the billion and specified an SNR.

I don't think you can, all you can do is cap your speed if you ever want to raise your SNR margin.

I'm unsure if 0.3 SNRM will amount to much change in sync speed.

I'm not quiet sure of why there's still so much of an argument behind this topic however I can confirm that the BT HH5a does support G.INP however it is only on downstream and has to have the correct firmware...

In test I saw a HH5a gain an extra 6mbps from G.INP after BT rolled out firmware that fixed the incapability...

In reply to a post by mlmclaren:

I'm not quiet sure of why there's still so much of an argument behind this topic

Because nobody has come up with any proof one way or the other

however I can confirm that the BT HH5a does support G.INP however it is only on downstream and has to have the correct firmware...

In test I saw a HH5a gain an extra 6mbps from G.INP after BT rolled out firmware that fixed the incapability...

That's not a measurable metric though.

A speed increase could be due to any number of things, the most likely being DLM deciding to change the sync speed banding.

What made you think it was G.INP, given that ECI cabs and ECI modems don't support G.INP?

This is exactly my finding having had the opportunity to use both an A & B HH5 on the same line and having seen what happened when g.inp was enabled on my local cabinet (back last year from what I recall).

I've seen no definitive information from OR, and all that people are ever able to point to is posts people have made to various forums, none of which provide links to authoritative data sources. The issues over the OR modems are, in contrast, well documented and evidenced.

Of course the two HH5 models do not provide definitive information on g.inp status (or interleaving for that matter), but it's possible to make reasonable inferences from behaviour, other stats, especially when it's possible to compare the two models on the same line.

My belief is still that the HH5 model A is able to support downstream g.inp, but not upstream, based on comparing the stats and behaviour on the same line. The only real advantage with the model B that I can see is that the upstream sync is about 10% higher. I find stability to be similar with resyncs normally only on a 15 day scheduled cycle.

nb. one slightly odd incompatibility between the A & B models is the power supply jack. It looks identical (as is the voltage), but the type B power supply won't fit a type A HH5 as it has a slightly "fatter" central pin (but a type A power supply fits a type B HH5).

Yeah, this illustrates the problem - people make these announcements but no stats are ever provided as a comparison and the Homehub doesn't mention G.INP in it's limited stats that are available.

Note the power supplies are different ratings so shouldn't be swapped anyway.

Also note the HH5B is much chunkier and much heavier than the HH5A.

In reply to a post by TheEulerID:

My belief is still that the HH5 model A is able to support downstream g.inp, but not upstream, based on comparing the stats and behaviour on the same line.

I'm of the same belief - that the HH5A supports G.INP downstream only. Batboy is convinced that G.INP is not supported in either direction.

Meanwhile, there seems to be no direct evidence - only experiments by people like yourself, able to see the end result with a variety of devices.

Note that the Openreach requirements in SIN 498 are that it must support G.INP downstream, while support for G.INP upstream has always been optional.

However, they've just released a new version of 498 (v7), which now indicates upstream G.INP is expected to be turned on "in due course", and "strongly recommends" that G.INP be implemented in both directions.

its a bit late to amend the requirements after millions of vdsl devicers have been rolled out?

We'd better drop VDSL2 then because of all the ADSLx devices in use.