In reply to a post by TheEulerID:

OK. Here's what I wrote in reply to you at 15:13:48 on Friday 5th (quoted in part as there's other stuff about g.inp). I assume you actually read it as you did leave a reply.

In reply to a post by TheEulerID:

g.inp does not add much of an overhead (unlike interleaving). Interleaving puts a whole lot of error correction data into the stream (in the time domain, hence the increase in latency). Unfortunately, it's a big overhead as most of that error correcting data will never be used, but it's transmitted anyway just in case. It's called "forward correcting" as all the redundancy information required for error correction is forwarded to the destination and there is no need (or even opportunity) to go back to the source.

http://forums.thinkbroadband.com/bt/t/4462964-re-myt...

As for you continuing to maintain that the HH5A does not support downstream g.inp, then that's your opinion, but at odd with what I've found and what the interview with the BT guy on Kitz. The OR guy clearly says that all modems support downstream g.inp, but upstream is optional. The sequence of events he describes, with the temporary imposition of interleaving during the implementation phase of g.inp is absolutely precisely what I saw on my own line at the time.

http://www.kitz.co.uk/adsl/ginp-retransmission.htm

tl;dr;

I think the sync speed being the same on a HH5A as on a HG612 with G.INP turned off is enough evidence that the HH5A doesn't support G.INP.

So that gnomic response (which I had to look up) means you couldn't be bothered to read it yet decided to reply anyway? I wonder what else you don't bother reading.

I mean I take your verbosity as an attempt to obscure so I ignore it.

I go to some lengths to explain why g.inp imposes only a small sync data overhead as opposed to interleaving for dealing with the same issue of impulse noise, and you dismiss it as obfuscation? Your arrogance is astonishing.

Edited by deleted (Sun 07-Feb-16 11:14:40)

I thought Impulse Noise Protection was dealt with by INP not Interleaving?

In reply to a post by BatBoy:

I think the sync speed being the same on a HH5A as on a HG612 with G.INP turned off is enough evidence that the HH5A doesn't support G.INP.

Well... its not... and following your previous comments on this thread I no longer have the 30 seconds on the day to keep on playing the same old soundtrack...

I've contacted a higher power for their opinion on the matter, and from here on out I will make sure you don't keep telling people incorrect information....

Both deal with impulse noise, just in different ways. Interleaving by spreading extra redundant error correction information across the time domain (with a substantial overhead in bandwidth and latency), whilst g.inp does it by having a retransmission system that works at the link level. Hence why so much bandwidth is lost when interleaving is turned on whilst g.inp has a negligible bandwidth overhead.

Note that interleaving can be imposed with different levels of overhead.

I will keep searching for proof one way or the other about the level of G.INP support provided by the HH5A regardless

I also note that INP can be imposed on fastpath as well as interleaved.