What Are G-LEFTRS?

Hi guys,

Just noticed a huge spike of noise on my line, no downstream CRC's occured but loads of G-LEFTRS did. Are these G.INP CRC's?

Thanks,

William

In reference to forum.kitz.co.uk/index.php?topic=15162.225:

LEFTRS = A counter of second-long periods where one or more LEFTR defects were logged. In this sense, it works just like the ES counter does, as a time-based monitor for the number of CRC errors

What does it mean? With CRC's being a thing of the past (anything which used to get a CRC error will now get re-transmitted), I think LEFTRS will be used as the equivalent of ES.

I did read that, but I'm still confused. Does that mean now we use G-LEFTRS' and CRC's to work out the ES count? Surely modems should take those into account when collecting ES'?

With CRC's being a thing of the past (anything which used to get a CRC error will now get re-transmitted)

That means they were CRC's but are now being re-transmitted.

I think I get it now, CRC's come from interleaving and G-LEFTRS come from G.INP.

Edited by deleted (Sun 26-Feb-17 22:14:58)

In reply to a post by WilliamGrimsley:

I think I get it now, CRC's come from interleaving and G-LEFTRS come from G.INP.

Nope.

Noise Protection is a layered affair, with multiple ways to try to fix, or otherwise cope with, errors in the underlying bitstream.

The first layer comes from FEC. Interleaving just makes FEC more effective.

Bitstream errors that can't be fixed by FEC are then dealt with by retransmission instead (or, colloquially, G.INP). If the retransmission also fails, then it can be re-retransmitted. More than once, possibly.

If retransmission of a block fails too many times, the modem gives up trying to send it. The missing block then becomes a CRC error.

There are counters that tell you how the various layers are performing in raw numbers: RS, RScorr, Rsuncorr, rtx-tx, rtx-corr, rtx-uncorr, LEFTR, and CRC all show this kind of information.

There are counters that show how often errors are happening, to calculate the "mean time between errors" information. These are FECS, LEFTRS, ES and SES.

So...

- CRCs come from bitstream errors that were severe enough to not be fixed by FEC, and happened every time the data was retransmitted N times, until G.INP gave up.

- LEFTRS come from second-long periods when retransmission was being used *so much* that ordinary throughput was reduced.

Both are a sign of prolonged bursts of noise, but they measure the impact on the line in different ways.

CRCs occur on Fast Path as well. Cyclic Redundancy Check. It just says there has been an error in the block. How the modem handles it is a different question.

Understood.

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

Yes, I know. Sorry, I meant they occurred from failed non-G.INP retransmission.

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

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

Edited by deleted (Sun 26-Feb-17 23:26:40)

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.