Please forgive my total ignorance - Why is is there this co-occurrence then? Straight interleaving has no overhead, by definition, just a time delay. So there must be a side order of something else that comes along when someone selects ‘interleave’ in this particular case then.

Basically I know nothing about FTTC and its quirks.

Or is there something in the g.993.2 spec itself that I should be looking at ? Not having read it properly.

@chrys About the max and bearer lines - my VMG 1312-B10A shows utter bonkersness in the max values - I can’t make any sense of it. For me it doesn’t seem to correspond to any x I can think of in “the max of x” as far as I can see

@j0hn - wait, I’m suddenly realising that I might not be reading this as intended - maybe. Are we saying that the value of the quoted sync rate drops by 10% if someone chooses interleave or that one has to take the sync rate and multiply it by 0.9 to get the effective throughput ? I just am being more than a bit slow here

RS codeword size. Reports the actual number of Reed-Solomon redundancy per codeword used in the latency path. Used with the R value to express the rate of FEC applied.

R Value - RS check Bytes (RFEC)

Number of (redundant/parity) bytes occupied by the Error Correction process (overhead).Often used to describe the level of error correction and can range from 0 to 20. The more check bytes that are used then the more errors can be corrected. The value 0 indicates no Reed Solomon coding. Use this value with N to express the rate of FEC applied as a percentage. eg R/N

If Chryralis posts his full stats you can see how much overhead is used by FEC on his line with Interleaving is enabled.

Post your own --stats and compare.

A line on FTTC that is fastpath or has G.INP will sync at the full rate and show a similar attainable.

Something likesync: 41,111attainable: 41,216

when interleaving is enabled there's an effect on both sync and attainable.overheads reduce sync.attainable is inaccurate * more info below.

for the same line interleaving would do something similar tosync: 36,132attainable: 43,324

sync reduced, attainable increased.

*an older inaccurate "basic" method of working out the attainable used by most modems (and Broadcom chipsets) exaggerates the attainable with INP/Interleaving. newer Lantiq chipsets/firmware use a newer "improved" method of calculating the attainable and don't do this.

There's an example on the forum of a user with a Lantiq chipset who's interleaved posting their stats before and after a firmware upgrade.Post 1 shows an Attainable way above sync and post 2 showed an accurate attainable.1st time I've seen an accurate attainable with interleaving which ejs suggests shows Lantiq using a better method of calculating attainable on newer firmware which makes sense.Can't find the post.

WWWombat detailed the different ways modems can calculate the attainable in this post

Please forgive my total ignorance - Why is is there this co-occurrence then? Straight interleaving has no overhead, by definition, just a time delay. So there must be a side order of something else that comes along when someone selects ‘interleave’ in this particular case then.

Basically I know nothing about FTTC and its quirks.

Or is there something in the g.993.2 spec itself that I should be looking at ? Not having read it properly.

@chrys About the max and bearer lines - my VMG 1312-B10A shows utter bonkersness in the max values - I can’t make any sense of it. For me it doesn’t seem to correspond to any x I can think of in “the max of x” as far as I can see

@j0hn - wait, I’m suddenly realising that I might not be reading this as intended - maybe. Are we saying that the value of the quoted sync rate drops by 10% if someone chooses interleave or that one has to take the sync rate and multiply it by 0.9 to get the effective throughput ? I just am being more than a bit slow here

the max prediction is quite possibly not accurate when interleaving is applied, there is coding gain which will push it up tho. The sync speed reduction comes from FEC which is enabled alongside interleaving. kitz mentions it here https://kitz.co.uk/adsl/error_correction.htm

John here is my (interleaved) stats from the midnight yesterday, you can fetch historical stats from link in my sig if you want also.