In reply to a post by WWWombat:

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.

Agreed- I also believe that the HH5A supports G.INP downstream but will go further and say its capable of supporting G.INP upstream as well if/when BT roll out a firmware update.

That's all very well but I'm actually running a HH5A and I assure you, it does not.

Disagree all you like, but please say whether you're running a HH5A or not.

In reply to a post by Chrysalis:

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

It's a bit late only if you need to tighten the requirements. Not to loosen them.

Upstream G.INP remains optional, so this requirement hasn't changed. The test specification has now clarified a couple of the tests to say which of them applies when the device only supports downstream G.INP, and which applies when the device supports both directions.

The V7 SIN does have an additional requirement: that the device support vectoring at the same time as downstream G.INP, and adds a test specification for this.

I wonder if that impacts any devices? I wonder what prompted them to add a test of the combination, given that they already have tests of the 2 features independently.

I'll read the ever-growing SIN some other time, but that last point is interesting as vectoring seemed to have disappeared into the long grass since G.FAST came along.

(I wonder if it is yet the longest ever SIN?)

Yes - I wonder about this too. Why keep concentrating on vectoring down in the details, when strategy is going elsewhere?

I wonder if it really means that vectoring isn't on the front burner, in the sense that there will be no programme to roll it out *deliberately* , but it remains on a back-burner.

I recall that the expected life of the electronics within the cab was perhaps half of that of the cab itself, though that is from a long time ago. Perhaps there will be a rolling programme of in-life upgrades to the cabs, even while G.fast is being rolled out, and we could expect vectoring to be a natural part of the upgrades then.

Or perhaps it is a backup plan, in case G.fast doesn't pan out.

Well I have both an HH5A & HH5B and both (in a downstream direction) give pretty well identical results on two lines (and on one of those lines, I actually saw what difference it made when it was enabled).

Quite how you can say for certain g.inp isn't working on your particular HH5A, I've no idea. You can only really work it out by inference on behaviour. In any event, just because it's not working on your particular combination doesn't mean it doesn't work at all. My experience indicates that it does.

I would prefer proof rather than guesswork. We can all guess. My guess is the HH5A doesn't do G.INP.

Edited by deleted (Sat 23-Jan-16 16:08:26)

In reply to a post by BatBoy:

That's all very well but I'm actually running a HH5A and I assure you, it does not.

Disagree all you like, but please say whether you're running a HH5A or not.

Yes, I have both a HH5A and a HG612 - both showed an improvement in my maximum attainable sync rate once G.INP was enabled on the line.

Not sure how you can assure me the HH5A doesn't have G.INP when all the evidence is to the contrary.

FWIW Openreach made support for downstream retransmission (G.INP) a mandatory requirement of its CPE testing for VDSL modems in June 2013. The HH5A was launched after this...

Because I prefer proof to conjecture and I assume the worst until proved otherwise. Incidentally G.INP is a lot more than an increase in sync. A sync increase can be due to fastpath rather than interleaving.

In reply to a post by BatBoy:

Because I prefer proof to conjecture and I assume the worst until proved otherwise. Incidentally G.INP is a lot more than an increase in sync. A sync increase can be due to fastpath rather than interleaving.

With respect, by all means prefer proof to conjecture and feel free to assume the worst until proved otherwise if you want.

BUT you are making categorical statements that the HH5A does not support G.INP which is not the same thing as not knowing if it does or not.

As I have two modems available - one of which is a HG612 - I can get view the modem stats for my line and tell that G.INP has been turned on. The sync speeds when I had fastpath and interleaving applied to this line instead were difference

You can't tell this is you only have a HH5A.

I have also stated that one of Openreach's requirements for its VDSL CPE connected to its network is that it supports downwards G.INP

Given the HH5A was launched after this are you perhaps suggesting that:

1. BT Retail didn't let Openreach test the HH5A?; or that
2. the HH5A failed the mandatory Openreach CPE spec but BT Retail rolled it out anyway?

Hopefully, you will accept both are unlikely.

I think you know that other VDSL modems using the same chipset as the HH5A also support G.INP..

If you still don't accept that the HH5A supports G.INP thats fine - its your view - but don't go about proclaiming it as "a fact" which is what you keep doing.

Edited by gt94sss2 (Sun 24-Jan-16 13:50:07)