In reply to a post by WilliamGrimsley:

So, do CRC's make a higher impact than G-LEFTRS or vice versa? I presume having decreased throughput is worse?

Good question.

I would tend to agree that a decrease in throughput is the worse outcome if it is significant; to see that, you want to be looking at the minEFTR value, to see how low throughput dropped to. LEFTRS just tells you how long a reduction has been going on for.

However, what amount of decreased throughput is significant?

I think there are two measures...
a) Does it get close to old-style FEC+interleaving? That would permanently steal 10-15% of your throughput.
b) A significant drop in throughput means a significant increase in retransmission ... which might show as a significant change to latency jitter. Unfortunately, we rarely measure this.

On the whole, I would rather my line was on G.INP than on old-style FEC+interleaving. That means I'd accept high LEFTRS values if the corresponding minEFTR was still significantly less than a 10-15% reduction.

In reply to a post by WilliamGrimsley:

I presume that when a CRC error occurs from both failed FEC and G.INP retransmission, the noise it occurred from is stronger?

I'd say the noise was more pervasive, than stronger. It could, for example, be the same strength, but the burst could last for longer. It could be the same strength and the same length of burst, but happen more often - where "more often" can be at irregular intervals, or at regular but shorter intervals.

Defeating FEC needs long bursts of noise, or a few short bursts that are strategically timed, but at short intervals.

Defeating Retransmission is unlikely to happen from *really long* bursts of noise (the link would likely resync first). Instead, it is likely to need lots of the bursts that defeated FEC in the first place.

But too many noise bursts will drop the link, so there's a balance needed.

In reply to a post by WilliamGrimsley:

For example, noise that generates 1 CRC with G.INP enabled would likely have been several without G.INP.

Yes, most likely.

IIRC, the original introduction meant that around 66% of lines went "error-free" because of G.INP. That means 0 ES and 0 CRC ... but presumably with the same noise happening.

Interesting. Thanks for the explanations as always, WWWombat.

In reply to a post by WWWombat:

b) A significant drop in throughput means a significant increase in retransmission ... which might show as a significant change to latency jitter. Unfortunately, we rarely measure this.

Surely it's the other way around that an increase in retransmissions might lead to a drop in throughput?

The delay from a G.inp retransmission is pretty low in the grand scheme and shouldn't be especially harmful to throughput. Higher level mechanisms mitigate the minimal jitter than a G.inp retransmission incurs.

In reply to a post by Ignitionnet:

In reply to a post by WWWombat:

b) A significant drop in throughput means a significant increase in retransmission ... which might show as a significant change to latency jitter. Unfortunately, we rarely measure this.

Surely it's the other way around that an increase in retransmissions might lead to a drop in throughput?

In terms of cause and effect, yes, it is the other way around. But I was in the middle of a conversation about whether a LEFTRS signified a higher impact than a CRC.

In that context, our starting point is LEFTRS - which is the monitor for reduced throughput.

Can I alter the original reply with
s/means/is caused by/
?

In reply to a post by Ignitionnet:

The delay from a G.inp retransmission is pretty low in the grand scheme and shouldn't be especially harmful to throughput. Higher level mechanisms mitigate the minimal jitter than a G.inp retransmission incurs.

I agree, one retransmission is relatively low.

The part I haven't figured is how many retransmissions of retransmissions are allowed. IIRC, I've seen that at least 4 transmissions are allowed, but I don't know what the maximum is.