Clearly quite a few errors are causing quite high interleaving and FEC.
If I read that correctly, about 25% of RS blocks are received with errors, but 99% of them get successfully corrected.
Your line is *definitely* in need of FEC and interleaving - it just wouldn't work otherwise!
One clarification on your post where my new understanding doesn't match my figures..
From what you said, I would have expected
Path = Max * (N-R)/N
as (N-R) is the number of useful bytes and N the total number.
However, for downstream, Rate = 75260 but Max * (N-R)/N = 70544,
In theory, that sounds about right.
Remember, though, that the "Max Attainable" alters based on current line conditions - particularly the current noise conditions - while the line speed and FEC/interleaving settings were all set in stone at the last sync (looks like 47 days ago). If it is noisier now than then, the "max attainable" figure will be lower.
What does your "--pbParams" output look like? If SNR is not 6dB, then line conditions have changed.
In practice, the Huawei also doesn't quite follow the theory. Whether it is a fault, or a consequence of the way it prepares the estimate, I don't know. When people swap between fastpath and FEC/interleaving, both line speed *and* max attainable change - usually in opposite directions.
The only thing we know for sure is that FEC is indeed eating capacity of your line - 16 bytes extra for each 64 bytes you receive