I’m hoping we can spot the specific points of difference between the data sets for the ‘high’ and ‘low’ states. Line #2, the latest, has these vertical jump transitions too, but not as large.
[Line #3 which is being discussed here is, in chronological order, the second pair in the first drop cable. (Line #4 is the first pair of an additional drop cable, which was put in later, and line #2 is #4’s later companion.) The numbering unfortunately ended up a bit weird because of AA allocating a ‘slot’ entry to a link of another type, other than a DSL line, a SIM, iirc, at some point in the history.]
It really is a damned nuisance losing such a big chunk of upstream, something like 20% or maybe more. I could increase the target SNRM to 9dB if things get really bad. Another problem is that I have to set the Brick’s upstream egress rates to be correct for the speed of each link, so unless I get those numbers right, ie low enough to cope when the rate drops because it happens to sync at a low SNRM time, then I am going to get terrible packet loss, dreadful speed and unreliability. So I won’t be able to ever get any benefit by resyncing during the high SNRM periods, not unless it is guaranteed to be able to hang on without dropping the link.
Another question: Can I get some idea of how many real errors, uncorrected corrupted upstream packets, are being seen when the SNRM is very low? That way I will know if Inhave another real problem.