Yesterday, the downstream CRC rate and ES rate were both steadily rising, also being higher at night as might be expected. The SNRM downstream was a mere 1.8 dB rather than the target of 3dB. In order to cool the rate of errors, which had risen to roughly one CRC error ever two seconds, I forced a resynch. The period after the resynch is also visible at the end of the graph below:
Here is the usual HCD picture in its current state of ‘ripening’ :
Summary of DSL links’ wellbeing and error counts
────────────────────────
* There are 3 modems in total. They are: #1, #2 and #4
* The active, contactable modems are: #1, #2 and #4
* The modems successfully queried are: #1, #2 and #4
───────────────────────
*** ***
*** There is some SERIOUS BADNESS ! ***
*** All is not well ! 😦 ***
*** ***
───────────────────────
--
* Sync rate: The following link has a really low downstream sync rate, below min:
Link #2 downstream: current sync rate 2380 kbps is below minimum expected downstream rate (2800 kbps) ❗Line #2 fault 🔺
--
*❗Link #2 defect detected: so-called ‘hollow curve disease’ in the downstream bit-loading. (-5.426 dB at tone 62 below chord 1: tones 40-85) ❗ Serious fault 🔺
--
* ES (less serious): The following links have a few CRC errors, at lower error rates, where the ES rate < 60 ES / hr (†):
Link #2 downstream: latest period: ES per hr: 13.02, mean time between errors: 276.5 s, collection duration: 553 s
Link #2 downstream: 'previous' period: ES per hr: 24.00, mean time between errors: 150 s, collection duration: 900 s
──────────────────────────────
(†) The duration of the ’latest‘ errored seconds (ES) collection
bucket is variable, with a _maximum_ of 15 mins. The buckets’
start times are always 15 mins apart. A ‘previous’ bucket's
duration is a fixed 15 mins. An ES is a 1 s time period in which one
or more CRC errors are detected. A CRC error is a Reed-Solomon
coding-uncorrectable error, ie. corrupted data is received that
cannot be recovered.
──────────────────────────────
◅ ◅ ◅◊▻ ▻ ▻