> may decline to accept the order.
Indeed, I had thought just that. And it also means all the unnecessary work of running a third drop cable out from the poles.
I’m getting packet loss now with this line (line 3). This is not good at all, so have informed AA. See:
In the snapshot above, the line status is red (down) currently because I had just forced a resync, in order to try and restore stability, and the link had not come back up yet.
It seems that all the problems are to do with data corruption in the upstream path of line 3; the following is downstream | upstream, note the ES counts for the period since the link came up:
Since Link time = 2 hours 3 min 55 sec
FEC: 304 35673
CRC: 19 2184
ES: 10 481
SES: 0 36
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Is ~233 ES per hour very bad news ? Seems to me that it is not good. Both downstream and upstream are set to a 6dB target SNRM. The presence of PhyR L2retx is presumably keeping the uncorrected error counts so very low compared to the upstream.
To me the SES is what stands out.
In my experience of years and years on DSL, My rule of thumb is ES on their own are not usually service affecting (unless they trigger DLM), but SES usually are, and yep you have SES on that upstream.
If you was getting a steady flow of ES but each ES was maybe just 1 or 2 CRC, you probably would have no red on your graph and wouldnt notice it, but looks like its coming in large bursts.