[I started writing this yesterday afternoon. It is written in the context of *not* having done the resync around 9pm yesterday; I'll cover that separately later]
I couldn't respond any further over the weekend, but it seems well worthwhile to have allowed some time for @NS' stats to accumulate. They are interesting.
Here's my analysis, ordered from cause, through direct effect, to indirect effect.
1. What Target?
The initial resync shows SNRM of 3dB for both upstream and downstream, suggesting that is the target.
2. Actual SNRM In Practice
Actual downstream SNRM rises from the starting point of 3dB to around 3.6dB later on Friday, but that kind of increase (0.6dB) seems to match the usual kind of improvement gained between 00:30 and mid-daytime - even before the resync.
Because @NS's SNRM cycles predictably each day, the speed achieved and the SNRM witnessed depends very much on the exact time of day that the resync happens.
We can see the "before" range was around 5dB-6.3dB, while the "after" range is now around 2.2dB-3.6dB. The difference turns out to be about 2.7dB, and has bought a speed improvement of 4.5mbps.
3. Raw FEC Rates
We see a marked increase in the FEC error rate - i.e. errors that were small enough they could be corrected.
This increase in FEC seems to occur very much in patterns, synchronised to the daily decline in SNRM: a wide spike from 4pm to 6am, with the worst being around 9pm. Notably, FECs seem to happen much more readily when SNRM declines below 3dB, even a little, while they stay relatively consistent when just above 3dB.
This might point out a useful rule-of-thumb: that we don't really want the line to drop below 3dB at any time; as @NS' line varies by around 1dB daily, this line might benefit from being on a 4dB target, so worst case never goes below 3dB.
4. G.INP Retransmission Usage
Errors that can't be handled by FEC get bumped into the retransmission mechanism.
In @NS' case, I think we can see a general increase in the "Retransmission TX" counts since the resync, but we don't see anything like the wide spike from 4pm to 6am that we see in the FECs ... suggesting that the FEC process has been very effective.
The other retransmission counts (Corr and Uncorr) tell us that the retransmission process is largely working - with just a few spikes in Uncorr.
5. CRC Errors
Errors that can't be handled by retransmission become CRC errors
The CRC graph doesn't show anything untoward has happened at all - a great result
6. Latency/Jitter
One outcome of additional retransmission would be the impact on latency: in particular, the increase in jitter.
I can't see a graph for @NS on this, so it is hard to tell whether there was any marked difference in outcome.
7. MTBE
The ultimate outcome is: How stable is the line? What is the impact to MTBE?
This gets shown to us in the ES and LEFTRS graphs, and the good news is that there seems to be virtually nothing changed about these.
I think there is an additional measure used by BT: FECS (an MTBE measure for FEC, in a similar way to ES being used for CRC); SIN 498 tells us that it is mandatory for the modem to be able to report this to the DSLAM. Unfortunately, there seem to be almost no modems that report this value. However, I'm sure we'd see a serious difference in this graph, if it were available to us.
8. Conclusion
@NS's line responded very well to a 3dB target, with the only exception being the spiked increase in FEC when actual SNRM values fell below 3dB.
The general increase in FEC was slightly visible in increased re-transmission rates, but the large spikes weren't replicated.
I can see that, for pure speed purposes, the line would work well enough at a 3dB target, but I can't help that a 4dB target would be best here.
