The point is, you need forward error correction as well as interleaving to fix transmission errors.

and, as per your edit, we have already seen where the sync speed on the HH5A on a Huawei cab is exactly the same as the sync speed on a HG612 on a Huawei cab with G.INP disabled

Edited by deleted (Sat 06-Feb-16 22:55:31)

In reply to a post by BatBoy:

That's right. It changed as soon as G.INP came back on my upstream 2 weeks later.

AFAIK the upstream was turned off completely until recently, the new rollout though may well of been tweaked so that DSLAM's take into consideration CPE's chips and compatibility.

I know that upstream retransmission wasn't enabled on my line in December before moving home, and my line was one to get it and then lose it when the fix for ECI/Lantiq problems was rolled out...

So the point here is that Lantiq chipsets do support G.INP.... TP-Link confirmed that and I'm almost sure that the same xDSL chip in the TP-Link W8890 matches that that is either in the ECI modem or the BT HH5a (and potentially PN H1)

Whether any updates to Lantiq based products has been done to make it further capable with G.INP (Upstream) I'm unaware though have seen a recent post with regards to some sort of upgrades to the ECI DSLAM's

In reply to a post by mlmclaren:

In reply to a post by BatBoy:

That's right. It changed as soon as G.INP came back on my upstream 2 weeks later.

AFAIK the upstream was turned off completely until recently, the new rollout though may well of been tweaked so that DSLAM's take into consideration CPE's chips and compatibility.

I believe that would be too complex to achieve. Far easier to turn G.INP off altogether.

I am intrigued by your missing 12 kbps.

In reply to a post by BatBoy:

I am intrigued by your missing 12 kbps.

I am also, however I've noticed it to be a BT thing and applied to new connections over the last few months, obviously a DLM profile of some sort...

I'm not going to complain over losing 12Kb/s... I'll wait until the next waive of VDSL2 activations in my building and then [censored] about crosstalk I suppose, though maybe G.INP will activate and gimme a wee boost to compensate

Did BT ever push that firmware in the end, and does your helpdesk stats still claim such a high attainable downstream figure like it did at the top?

In reply to a post by mlmclaren:

Did BT ever push that firmware in the end, and does your helpdesk stats still claim such a high attainable downstream figure like it did at the top?

Not yet. BT don't work week-ends - including Fridays, but I'll chase it up next week. My stats are unchanged with the exception of the uptime which merrily increments.

For heaven sake, I've said interleaving uses FEC. It uses a distribution in the time domain of redundant data to allow error correction even when impulse noise wipes out short stretches. The kitz item on g.inp support in Openreach confirms what I said that downstream support is compulsory (which is what the HH5 A does) whilst upstream g.inp is optional.

Just reminded me to check to see if I had a reboot of any sort... however I've not had my HH up for 14 days without disconnecting it from power for some reason or other

In reply to a post by TheEulerID:

For heaven sake, I've said interleaving uses FEC.

where?

The kitz item on g.inp support in Openreach confirms what I said that downstream support is compulsory (which is what the HH5 A does

n't)

Edited by deleted (Sat 06-Feb-16 23:35:52)

In reply to a post by BatBoy:

In reply to a post by TheEulerID:

For heaven sake, I've said interleaving uses FEC.

where?

The kitz item on g.inp support in Openreach confirms what I said that downstream support is compulsory (which is what the HH5 A does

n't)

You have already said it does support G.INP.... you haven't provided any evidence to suggest it doesn't, all you've provided is invalid statistics that show impossible achievement's and also irregularities in your hub compared to others....

I'm saying it's capable after my own testing, others have tested and say its capable, the certification of the device says it capable... all your doing at the moment is giving out inaccurate information and not even considering the facts or contributions made by others...

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