I've also noticed that I am now getting 8 times the amount of FEC's recorded. I gather this is G.Inp doing its job?
Yes, sort of, but the terminology needs cleaning up.
DLM has a number of tools in its chest when deciding how to intervene to reduce errors, and the introduction of G.INP introduces a new one - more properly known as retransmission.
When we talk of G.INP being active, DLM will have actually turned on 3 of its tools - retransmission, FEC error correction and interleaving. The latter two are the same as used in the old-style intervention, but when used alongside retransmission, they aren't used anywhere near as harshly. Interleaving, for example, only causes 0.2ms of delay instead of the previous 8 or 16ms.
DLM wants all 3 components working together.
When you see FEC errors (aka RSCorr) accumulate, you are really seeing errors corrected by the FEC portion of the toolbox (FEC successes?), but they have not yet caused a retransmission. It is where you see see FEC failures (aka RSUnCorr) that things progress into retransmission - which is what we really mean by "G.INP".
To see how many retransmissions have happened, you have to look at the rtx-tx graph, showing the number of retransmissions actually sent. If the retransmission process works, you'll find that the rtx-c graph (this one shows the number of retransmissions that are received correctly) matches. If, however, some retransmissions of retransmissions are needed, then the rtx-tx graph will be bigger than the rtx-c one.
Finally, if things get so bad that a succession of retransmissions of retransmissions all fail, the rtx-uc graph starts to accumulate. Things will be getting bad if this happens much.
To summarise: now you are seeing FEC errors accumulate, you are seeing DLM's error-correction toolbox being called into action. Not quite retransmission, but part of the complete picture of how DLM wants to use G.INP's retransmission.
This post has the potential to be confusing too. I hope not, though. Maybe more beer, not less
