I looked at line 2 in more detail. I did in fact find some slight evidence that it had been struggling. There were some errored seconds on the downstream, and it was the only link with ES. This was in downstream not upstream though. Could the modem have been struggling with receiving the inbound return TCP ACKs associated with this huge test upload? (the 15 min backup of my iPad to the Apple servers) I couldn’t see enough CRCs to explain this.
I resynched modem #2, and the downstream dropped because the d/s sync had been well below the target 3dB (down to 1.7-2.2dB) in the early morning. Resync caused downstream sync rate to go down to a very slow 2.828 Mbps, which is the slowest of the four, and poor historically, aside from faults. It was a very noisy time of day, in the very early morning, and so a time to achieve the slowest speed and max reliability from a resynch operation.
However more importantly for present purposes, the upstream resynched at 509kbps down from a prior 519kbps. So slight evidence of ‘pressure’ on the upstream, but extremely weak surely? More significantly perhaps, the u/s SNRM had been at 5.5dB instead of the 6dB target. Drooping below the u/s target is unusual (for the u/s) with these links. So it is possible that link #2 could be said to be struggling.