Kitz Forum
Broadband Related => ADSL Issues => Topic started by: Weaver on July 14, 2022, 06:49:38 AM
-
Here we go again, line 4, this time. HCD just like before, unfortunately the first signs of the same disease are showing in the SNRM vs tones graph measured by the modem, with slight loss of downstream sync rate. The very distinctive shape of a dent in the SNRM vs tones graph is what I termed before ‘hollow curve disease’. No real problem yet except for the slight speed loss, and can’t call OR out yet to find the incipient fault. As before I just have to wait until it gets to a really really bad speed loss and becomes unusable. Just ask if you would like any detailed pictures. God, roll on FTTP / FTTPoD.
Asked AA to keep an eye on this line for me as it develops, and asked if anything funny visible in their tests yet.
Line 4, SNRM vs tones:
(https://i.postimg.cc/K8vZ12qB/76-CB3-AA8-C42-E-4-A95-BAFE-F0-CD677-B413-E.png)
Line 4 detailed stats and errors:
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 308 Kbps, Downstream rate = 2996 Kbps
Bearer: 0, Upstream rate = 355 Kbps, Downstream rate = 2691 Kbps
Link Power State: L0
Mode: ADSL2 Annex A
TPS-TC: ATM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 2.9 5.8
Attn(dB): 65.5 41.4
Pwr(dBm): 18.2 12.4
ADSL2 framing
Bearer 0
MSGc: 52 11
B: 18 4
M: 8 16
T: 5 9
R: 16 16
S: 1.7778 7.0459
L: 756 109
D: 1 4
Counters
Bearer 0
SF: 5559084 369689
SFErr: 9 1
RS: 201516811 3849449
RSCorr: 15758 1377
RSUnCorr: 9 0
ReXmt: 3003 0
ReXmtCorr: 3003 0
ReXmtUnCorr: 9 0
Bearer 0
HEC: 7 1
OCD: 0 0
LCD: 0 0
Total Cells: 571851294 75488003
Data Cells: 45393609 5761466
Drop Cells: 0
Bit Errors: 477 20
ES: 829 11
SES: 25 0
UAS: 184 163
AS: 90113
Bearer 0
INP: 28.00 2.00
INPRein: 0.00 0.00
delay: 8 7
PER: 16.11 16.84
OR: 28.80 8.07
AgR: 2707.42 361.91
Bitswap: 9666/9667 319/319
Total time = 22 days 3 hours 58 min 43 sec
FEC: 411735 45157
CRC: 2931 13
ES: 829 11
SES: 25 0
UAS: 184 163
LOS: 1 0
LOF: 9 0
LOM: 0 0
Latest 15 minutes time = 13 min 43 sec
FEC: 93 6
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 111 8
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 3 hours 58 min 43 sec
FEC: 2519 140
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 18380 1274
CRC: 63 1
ES: 42 1
SES: 0 0
UAS: 60 60
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 1 days 1 hours 1 min 53 sec
FEC: 15758 1377
CRC: 9 1
ES: 9 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
All modems:
Status of each modem
─────────────────
* 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
--
Link #1 sync rate: downstream: 2.680 Mbps at SNRM 2.9 dB; upstream: 650 kbps at SNRM 5.9 dB
Link #1 uptime: 5 days 13 hours 10 min 27 sec
--
Link #2 sync rate: downstream: 2.773 Mbps at SNRM 2.9 dB; upstream: 519 kbps at SNRM 7.9 dB
Link #2 uptime: 20 days 13 hours 43 min 41 sec
--
Link #4 sync rate: downstream: 2.691 Mbps at SNRM 2.8 dB; upstream: 355 kbps at SNRM 6.1 dB
Link #4 uptime: 1 day 1 hour 4 min 9 sec
--
◅ ◅ ◅◊▻ ▻ ▻
-
b*cat nods and thinks "Yes, once again. As before." :(
So you are now in that wait and see mode, waiting for the fault to "ripen".
-
Exactly. I’ve asked AA to just watch and decide when to spring. I hope they’ll remember about it and make the decision when to pounce for me. I wouldn’t have known anything without the HCD detector code firing off an alarm. It successfully detected HCD to begin with, but then the shape shifted and the code no longer picked the problem up, so the new algorithm was needed. I’ve noticed that the SNRM values in the curve do ripple and change quite frequently, by very small amounts.
So now the three chords have rhs endpoints at tone 60 / 70 / 80 approx values in each case, as some are dynamically adjusted slightly by stalactite detection and avoidance. In one case, the test condition is not just that the y-value (ie SNRM) of the curve at the test point / chord midpoint is below the chord, but it has to more than a certain minimum amount below, a small amount. This is to guard against bogus HCD reporting due to noise / ripple. It does reduce the effectiveness of the detector though and means it can miss HCD cases, so I have not used this technique unless experience suggests there’s a real need in a particular case. It’s not used with chord 3; I think only with chord 2, the mini-notch detector.
I need to update the documentation for this code accordingly now.
Now I remember - the very first indication that anything odd was happening was a retrain for no reason, which reduced both the downstream and upstream rates slightly. This made me run my health checker program, which includes full HCD detection, and that reported the alarm. Looking back, there was no large amount of errors that would perhaps force a retrain, so it was a mystery to me. If I recall correctly, there were zero CRC errors in both directions for a substantial number of hours before the retrain, even at downstream target SNRM= 3dB and upstream target SNRM= 6dB. And the line wasn’t in the BT ‘training period’ iirc.
-
And while we’re waiting for the line 4 fault to brew, line 2 has now also suddenly gone spectacularly bad in one leap. Line 2 did a retrain on Sun evening, and lost a lot of downstream sync rate, down from 2.7 Mbps to ~1.95 Mbps with very very bad HCD, a 6dB deep hollow:
Links’ sync rates:
link #1: downstream: 2.680 Mbps, upstream: 650 kbps
link #2: downstream: 1.963 Mbps, upstream: 512 kbps
link #4: downstream: 2.691 Mbps, upstream: 355 kbps
◅ ◅ ◅◊▻ ▻ ▻
I’ll post up the picture of HCD horror if anyone is interested.
-
. . . line 2 has now also suddenly gone spectacularly bad in one leap.
:o :(
-
Here’s the latest line 2 horror show:
(https://i.postimg.cc/FRpFLKz9/81-FE5993-CE60-4979-BCAB-79-BE4-D712-B0-C.png)
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 916 kbps is below minimum expected downstream rate (2700 kbps) ❗Line #2 fault 🔺
--
* SNRM: The SNRM of the following link is out of range:
Link #2 downstream: current SNRM: 8.8 dB is too high; above the expected maximum SNRM ( 3.8 dB )
--
* HCD:❗So-called ‘hollow curve disease’ (HCD) defect detected in the downstream SNR-vs-tones curve. Serious fault. 🔺
Link #2: Summary: tone 62 is 0.55972 dB below chord 1: (tones 40-25.9375); ❗
Link #2: Details: chord 1: [ tone 40: 22.5 dB; curve midpoint test tone 62: 16.5625 dB; tone 25.9375: 25.9375 dB ]; chord midpoint test tone 62: 17.12222 dB.
--
* HCD:❗So-called ‘hollow curve disease’ (HCD) defect detected in the downstream SNR-vs-tones curve. Serious fault. 🔺
Link #4: Summary: tone 62 is 2.225 dB below chord 3: (tones 40-70);❗
Link #4: Details: chord 3: [ tone 40: 37.0625 dB; curve midpoint test tone 62: 34.1875 dB; tone 70: 34.625 dB ]; chord midpoint test tone 62: 36.41250 dB.
--
*❗ES (serious): Links with CRC errors at higher error rates, where the ES rate ≥ 60 ES / hr (†):
Link #2 downstream: 'previous' period: ES per hr: 1664.00, mean time between errors: 2.16 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
errors are detected ie. corrupted data is received that either can not
be recovered by back-calculation using the additional redundant
error correction information included with each message, or by
being resent a certain maximum number of times without being
received corrupted.
──────────────────────────────
◅ ◅ ◅◊▻ ▻ ▻
Status of each modem
────────────────
* 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 ! 😦 ***
*** ***
───────────────────────────────────────
--
Link #1 sync rate: downstream: 2.680 Mbps at SNRM 2.9 dB; upstream: 650 kbps at SNRM 6.1 dB
Link #1 uptime: 9 days 9 hours 17 min 11 sec
--
Link #2 sync rate: downstream: 916 kbps at SNRM 8.2 dB; upstream: 512 kbps at SNRM 8.2 dB
Link #2 uptime: 7 hours 2 min 49 sec
Link #2 ES: downstream: latest 15 minutes time: ES 1610.53 per hr; MTBE 2.24 s; bucket duration 380 s
Link #2 ES: downstream: previous 15 minutes time: ES 2280 per hr; MTBE 1.58 s; bucket duration 900 s
--
Link #4 sync rate: downstream: 2.691 Mbps at SNRM 2.5 dB; upstream: 355 kbps at SNRM 6.1 dB
Link #4 uptime: 4 days 21 hours 10 min 51 sec
--
◅ ◅ ◅◊▻ ▻ ▻
Line 4 latest graph. Classic early HCD::
(https://i.postimg.cc/y6nKFPCB/40-EB4448-E7-E2-4-B1-F-8-F8-F-A759-C8-C9-D6-A8.png)
-
Interesting to know these Hollow Curves are a fault condition, I had them on my ADSL service for its entire duration which survived numerous pair swaps. I might dig out some old DMT samples if I ever get bothered.
-
Wow, Chrys - that says to me that they are some reasonably well-known electrical and possibly electro-mechanical fault conditions. I’d love to know exactly what the Openreach engineers did to repair things when they actually did something, as opposed to turning up and fixing the fault by the magical influence of their very arrival or presence.
Note about line 2: the line 2 downstream CRC error rate is so ridiculously high - see previous post - that it’s out of control and will, I assume [?], muck up the performance of the whole bonded set, so I might need to take line 2 down but I want AA to have an opportunity to see it obviously. So I’ve left it up for now but have increased the downstream target SNRM to 9dB from 3, and even that is nowhere enough, it’s that bad. Note that the figures posted are with 9dB downstream target SNRM set for line 2 and that’s going to need to go right up further.
-
In my case weaver it was pretty much a wont fix line is within spec from openreach and this included my first stint on AAISP on that line, AAISP did get me moved to a different line card vendor as well as some D side pair swaps and the second vendor had better handling of line errors as well as a few more usable strong tones. I eventually got an engineer to admit the fault needed very expensive roadworks on an extremely busy road around the city centre on the E side, the source of the fault "might" still exist today, but I am on VDSL now with fibre now been used E side it bypassed the issue.
My HCD was bad enough that 15db SNRM and interleaving couldnt control the stability (at the time was Openreach's most stable DLM profile).
-
Amazing! Thanks for letting me know!
Update, I reported lines 2 and 4 to AA on Monday morning, OR engineer arrived Tuesday morning, booked for line 2 (only) pretty impressed by that. Both lines sorted straight away. Engineer, among other things, went up the pole by the roadside below my house - that trouble spot again. It seems that line 4 was fixed by OR magic, of the kind that has fixed faults at many a callout in the past, yet we have never understood how.
=========== F I X E D !! ==================
I told AA that both lines were looking splendid, apart from a slight loss of speed 50-100 kbps, so both tickets were to be closed. I noticed that the next morning AA added a note in clueless “Note LTOK Work Point: JB26”. I know what a JB26 is but I don’t understand how that note got put there as I can’t see it in the engineer’s notes.
The engineer was a known dreaded moaner, who has moaned and complained to my wife before. He shall not be named in public. He complains to my wife about [possibly inaccurate 3rd party account] "you keep on turning it up and it can’t handle it" (the warp engines cannae take it captain) "it" presumably being the downstream target SNRM which as we all know must not be turned up too high as it makes lines fail. My wife was very worried about "him coming again". I told her to turn the moaner over to me, or to AA, and Janet had the required AA contact number at the ready. On this occasion Janet handled him by saying "it’s no good telling me, I’m not the techie one - It means nothing to me", so all was well. I have told her if suchlike cause her any anxiety then I will ask AA to ‘have a word’, but I’m very worried about OR overreaction.
The line 4 has no HCD at all, so as I said, I have no idea what happened and the engineer was not booked to do anything to line 4 - there’s no mention of it in the notes below. I checked the clueless log for line 4 today and there’s nothing significant mentioned in it.
Here are the engineer’s notes as sent to AA and included below, taken from the clueless log for line 2:
Wednesday 11:21:16 Note LTOK Work Point: JB26 aa@a
Monday 11:37:13 Wednesday 10:15:05 ToDo Check Line since an SNR Reset was run aa@a
Tuesday 16:10:53 Wednesday 10:14:57 BT Fault 5-894563588028 Please accept clear if fault resolved. If rejected an SFI appointment will be offered.
Local access network between Exchange and End User;Fault rectified in underground network aa@a
Wednesday 00:56:13 SMS to janet: Delivered to handset 2022-07-20 00:56:10 SMS
Wednesday 00:56:11 Sent KCI sms janet 2022-07-19 23:08:40 DSL line up (down 80 seconds) KCI
Tuesday 23:08:44 Deferred KCI sms 2022-07-19 23:08:40 DSL line up (down 80 seconds) KCI
Tuesday 23:08:43 Tx rate (adjusted) 2092104 to 2338182 (rx 512000) -Auto-
Tuesday 23:07:26 Cancelled KCI sms 2022-07-19 23:07:20 Line down (LostCarrier) [cancelled deferred KCI] KCI
Tuesday 23:06:12 Tuesday 23:06:51 Test SNR reset: RateBandDS=160-24384 InterleaveLevelDS=On TargetMarginDS=3dB RateBandUS=32-Uncapped InterleaveLevelUS=On TargetMarginUS=6dB:SNR Recalculation initiated which will enable the line to reach optimum speed, stabilization retrains can be expected over the next couple of days. weaver@a
Tuesday 23:06:07 Update Update RateBandDS=160-24384.6dB->160-24384.3dB weaver@a
Tuesday 15:37:15 Tuesday 16:10:53 BT Fault 5-894563588028 Notes as it is received from OR
What did the end customer describe as the primary issue ?: 4012.04-Customer Report: End customer advised there is a broadband issue.
Specifically where did you resolve the fault ?: 1619.03-\n\n Actions to resolve: Engineer has resolved the fault located at the D-side including aerial cables / lead-in / block terminal.
What were the visible signs that caused the fault ?: 1613.36-The fault was located outside the end customer's curtilage and shown by damp / corrosion to wire / cable.
What did you do to fix the fault ?: 1614.33-The fault was fixed by clearing in joint.
Where / how did you perform the final Eclipse / FastTest / xDSL ?: 3839.03-\n\n Final alternate test results: Final FastTest performed from the customer premise.
What was the result of the final Eclipse / FastTest / xDSL ?: 3853.01-The test passed on 19/07/2022 15:30:15. BT
Tuesday 15:37:00 Tuesday 15:37:15 BT Fault 5-894563588028 Notes as it is received from OR
What did the end customer describe as the primary issue ?: 4012.04-Customer Report: End customer advised there is a broadband issue.
Specifically where did you resolve the fault ?: 1619.03-\n\n Actions to resolve: Engineer has resolved the fault located at the D-side including aerial cables / lead-in / block terminal.
What were the visible signs that caused the fault ?: 1613.36-The fault was located outside the end customer's curtilage and shown by damp / corrosion to wire / cable.
What did you do to fix the fault ?: 1614.33-The fault was fixed by clearing in joint.
Where / how did you perform the final Eclipse / FastTest / xDSL ?: 3839.03-\n\n Final alternate test results: Final FastTest performed from the customer premise.
What was the result of the final Eclipse / FastTest / xDSL ?: 3853.01-The test passed on 19/07/2022 15:30:15. BT
Tuesday 10:29:42 Tuesday 15:37:00 BT Fault 5-894563588028 The fault has reached PONR, amend/cancel currently can not be accepted BT
Modem 2 SNRM-vs-tones:
(https://i.postimg.cc/ZnwMjzg7/7735798-A-6-CE4-4072-A3-AA-61-C1-CC46-DAE6.png)
Modem 4 SNRM-vs-tones:
(https://i.postimg.cc/sxn3W8Jy/0-DB35484-B43-C-40-DF-8-ADE-6-AAEADC34993.png)
-
Update, I reported lines 2 and 4 to AA on Monday morning, OR engineer arrived Tuesday morning, booked for line 2 (only) pretty impressed by that. Both lines sorted straight away. Engineer, among other things, went up the pole by the roadside below my house - that trouble spot again. It seems that line 4 was fixed by OR magic, of the kind that has fixed faults at many a callout in the past, yet we have never understood how.
=========== F I X E D !! ==================
I told AA that both lines were looking splendid, apart from a slight loss of speed 50-100 kbps, so both tickets were to be closed. I noticed that the next morning AA added a note in clueless “Note LTOK Work Point: JB26”. I know what a JB26 is but I don’t understand how that note got put there as I can’t see it in the engineer’s notes.
So you now have three working pairs, once again. Excellent. :)
As for the "Note LTOK Work Point: JB26" perhaps A&A can enlighten you?
At the pole top, there is a BT66 in which the pairs from the two aerial drops are joined to a multipair cable. (Five pair? or ten pair?) That multipair cable then descends the pole and, at ground level, enters a joint closure (A standard, clip, joint closure (maybe)? What I describe as a "giant's thimble".) on one of the larger multipair cables (running from NSBRD to Heasta properties further down the hill). So, at the pole, there are two joints in each pair (separated by the height of the pole) on the way to Torr Gorm where water ingress could cause corrosion.
-
A further thought on the enigmatic: "Note LTOK Work Point: JB26" phrase.
A very reliable source has just sent me a link to a supplier for a "BT Joint Box 26 (https://maenetworks.co.uk/category/external-underground/joint-boxes-covers/bt-joint-box-26/)". I can't imagine one of them being anywhere out on the high moor or at the foot of the lower (roadway) pole.
However there might well be one of those joint boxes either on the A87 before the turn onto the road to Heasta or on the early part of the Heasta road, by those last few houses at Harrapul, before the start of the moor. If that is the case, perhaps it was the last point of easy access to the pairs before the lower (roadway) pole is reached and, at that point, "LTOK" - only becoming "LTNOK" in your office.
-
I did ask A&A what LTOK means and they simply said "line test OK". I’ve just remembered - line 2 is my "fourth line" concerning which there was some fuss with OR trying to find additional E-side pairs (was it?) and something involving the green cab by the Claymore.
-
I’ve just remembered - line 2 is my "fourth line" concerning which there was some fuss with OR trying to find additional E-side pairs (was it?) and something involving the green cab by the Claymore.
It was probably the E-side. I recall that there needed to be some rearrangement for the provision of the fourth circuit but it was not clear exactly where the rearrangement was made.
-
That didn’t last long. The so-called ‘repair’ failed on Sat afternoon. Line up-down, huge packet loss. Have let AA know.
-
That didn’t last long. The so-called ‘repair’ failed on Sat afternoon.
:( Line two or line four?
-
Oh sorry, line 2. The moaning OR engineer will be back to the scene.
-
I wonder how many engineers book the day off when they see you reported a job? ;)
-
We don’t always get the same fellow, not at all. But we have been getting him quite often in the last year or so.
Here’s the pretty line 2 picture from A&A:
(https://i.postimg.cc/qvm0jG5P/D1-C1510-A-E8-F9-4-DF2-A193-10091-C3009-FD.jpg)
-
Now as well as the line 2 second failure, last night, Sunday, Line 4 dropped to downstream 1.67 Mbps approx, so AA has booked two more OR appointments for me.
-
Is it stable with a higher SNR margin?
-
Good point Chrys. The downstream SNRM has drooped all the way down to 1.1 dB. That’s pretty useless. My modem well-being summary program goes mental, ringing bells about line 2: suffers from low downstream SNRM, ridiculous ES and CRC count right now, and early-stage but very distinct HCD. I’ve just forced a resync and I’ll see what it’s like. But after that I’m following your advice, and if need be I’ll increase the downstream target SNRM to 6 dB until Openreach turn up. Again.
-
Engineer here today, very friendly and helpful. Booked to look at both lines 2 and 4. The lines wouldn’t play ball though. I’ve been quite exhausted and unwell over the last couple of days so I’ve missed what’s been going on with the lines. Line 2 recovered on Sunday afternoon and has been perfect ever since, and line 4 had no problems over the same period. Power was off for many hours yesterday so I wasn’t recording stats. Today I can’t see anything wrong in the slightest with line 4; line 2 shows the smallest case of HCD, but nothing wrong as a result apart from a small speed loss. When I feel a bit better this evening, I’ll review everything.
Talked to engineer at length; showed friend johnson's HCD picture for line 2 and explained that it was a symptom of future trouble. Showed line 1 SNR vs tones curve for comparison. Then showed AA clueless CQM history line 2 and the badness on Sat and Sun, but goodness ever since, apart from the power outage on Tue. Our friend told me that the extreme north of the island is already equipped with FTTP; Gleann Dàil and Dùn Tuilm are two of the remotest spots in the north. He said OR engineers themselves are doing surveys up there, presumably because there simply are no contractors. I also heard about a holiday cottage where an owner had paid £20 for FTTPoD. Is that 1 Gb&bps?
A colleague is taking a look at line 2 from the PCP at the Claymore restaurant on the main road, using some additional software and or hardware, AJAX he might have said but he too was unsure about the name. This should hopefully provide some more insight.
-
I also heard about a holiday cottage where an owner had paid £20 for FTTPoD. Is that 1 Gb&bps?
Isn't there a k (kilo) multiplier missing from that sum? £20k would be more like it. :-\
As for the speed, it would be whichever Openreach product the ISP is selling onto the end-user.
-
I see. I was thinking of the fact that the B&B will actually be offering supposed 1 Gbps to visitors, what, 450 Mbps being the true figure, no? Any more being a matter of luck.
After the engineer had left, I emailed AA straight away, because the speed of line 4 was down to 1.1 Mbps downstream. AA sent me a reply which I missed because I was asleep. When I woke up, a couple of hours later, I looked at that modem and saw HCD had appeared for the first time in many days, as it had gone into hiding for a while for part of last week and into weekend. AA tried to perform a remote SNR reset to restore sanity to the very high downstream SNRM, but for some reason the remote <something> failed so they had asked me to do it. Telnetted into the modem and forced a resync, which had the desired effect, the downstream SNRM being back to 3dB and the downstream sync rate is currently 2161 kbps, about 500k below what it should be because of the >6dB deep HCD. Will perhaps need to increase the d/s target SNRM I suspect, if the error rate is up, as has happened before with HCD. Will check error rates later. Usual pictures of horror available showing initial HCD depth this afternoon and the SNR-vs-time history too.
-
I see. I was thinking of the fact that the B&B will actually be offering supposed 1 Gbps to visitors, what, 450 Mbps being the true figure, no?
If the circuit is provisioned as the Openreach 1 Gbps product then, after taking into account the Ethernet frames and other overheads, the data throughput will be ~940 Mbps. You might like to have a look at GigabitEthernet's "FTTP questions (https://forum.kitz.co.uk/index.php/topic,27137.0.html)" thread.
-
Apologies, I was thinking that 450 Mbps is the only guaranteed throughput figure - is that vaguely right or nonsense? That 900 Mbps is an ‘if you’re lucky’ figure if few other users are around ?
-
Apologies, I was thinking that is it 450 Mbps is the only guaranteed throughput figure - is that vaguely right or nonsense?
I'll have to let someone else answer that question, as I have zero experience (as an end-user) of such a service.
That 900 Mbps is an ‘if you’re lucky’ figure if few other users are around ?
Basically "yes". A GPON, as built by Openreach in the UK, has a 2.488 Gbps DS (to the end users) and a 1.244 Gbps US (from the end users) upper limit. Openreach plans and deploys GPONs with a 1:32 split (but only use the first 30, keeping the final 2 in reserve).
The next pon up in the series is XGPON which, if I am remembering correctly, has a 10 Gbps DS and a 2.5 Gbps US upper limit.
Then there is XGSPON which is symmetrical XGPON, with a 10 Gbps DS and 10 Gbps US upper limit.
(Of course none of that has anything to do with the HCDs you are seeing with your ADSL2 circuit(s)!)
-
No, but it’s very valuable! And I believe it was I who started it. :)
-
Yes, you did. :)
I was just a little concerned that a passing moderator might take some action, as we have meandered way off topic. :D
-
Line 4 has been dead for a few days until mid-morning when A&A gave it a kick by initiating a test and somehow brought it back to life. Downstream sync rate dropped from 1.4 Mbps to approx 0.4 Mbps. AA is arranging another engineer visit. Quote from AA today:
I'll get a fault raised. I think we should approach BT on what the long plan solution is here as we can't keep going on like this. We've had countless engineers out with no long term fix out in place.
-
Hmm . . . We can only wait and see what will be the Openreach response. :-\
-
HCD error report, tested just now, 21:30 UTC:
--
* HCD:❗So-called ‘hollow curve disease’ (HCD) defect detected in the downstream SNR-vs-tones curve. Serious fault. 🔺
Link #4: Summary: tone 62 is 8.25139 dB below chord 1: (tones 40-85); ❗
Link #4: Details: chord 1: [ tone 40: 22.75 dB; curve midpoint test tone 62: 15.8125 dB; tone 85: 25.4375 dB ]; chord midpoint test tone 62: 24.06389 dB.
Latest picture of horror, taken earlier this afternoon (so numbers don’t match the above):
(https://i.postimg.cc/593K67Sr/27-B4-E0-EA-CB4-C-4-BB9-9225-856-FC0-EB96-E9.png)
-
The problem here is that Openreach could throw in the towel and give up trying to fix the line. Although you have the right to request a 'decent' broadband service the obligation for one to be supplied appears somewhat limited - https://www.ofcom.org.uk/phones-telecoms-and-internet/advice-for-consumers/broadband-uso-need-to-know.
-
I didn’t think that that meant starting up a dispute with AA though. Do you follow?
Is this costing AA, OR, or BTW ? (From RevK’s postings of many years back, he would wish for BTW to pay for repairs because AA is paying BTW for ‘broadband’ and its supposed to be working. Actually a thought occurs to me, if that’s correct, then it would be OR vs BTW in a shouting match then?)
Mind you, even if OR had a strop and refused to fix the line, then I would just order a new line and then do a cease. That worked last year fine.
AA told me "SFI task has been raised for 03/08/2022 PM slot." I’ve heard this term many times but I don’t know what exactly an SFI engineer is.
-
AA told me "SFI task has been raised for 03/08/2022 PM slot." I’ve heard this term many times but I don’t know what exactly an SFI engineer is.
SFI -- Special Faults Investigation. More correctly, SFIA -- Special Faults Investigation Assure. An Openreach service (https://www.openreach.co.uk/cpportal/services/product-services/special-fault-investigation-assure) available to ISPs to investigate problematic DSL circuits.
Also see the Kitz Glossary 'S' Page (https://forum.kitz.co.uk/index.php?topic=4620.msg108576#msg108576).
-
Does that mean a different grade of OR engineer? What’s the difference in tasks performed? The problem is that some of the OR engineers I’ve had in the past don’t (I suspect) understand DSL thoroughly, but I’m perhaps being very unfair.
-
Does that mean a different grade of OR engineer?
Yes. I would expect to see a Black Sheep equivalent. Someone who has a good understanding of the DSL technology.
What’s the difference in tasks performed?
Sorry, I can't answer that. Perhaps others will be able to provide some input? (b*cat looks towards . . . the usual suspects. ;) )
The problem is that some of the OR engineers I’ve had in the past don’t (I suspect) understand DSL thoroughly, but I’m perhaps being very unfair.
Understood. And yes, there are those who are experts in telephony circuits but not DSL circuits.
-
Good luck on line 4 weaver, let us know how it goes. :)
-
Does that mean a different grade of OR engineer? What’s the difference in tasks performed? The problem is that some of the OR engineers I’ve had in the past don’t (I suspect) understand DSL thoroughly, but I’m perhaps being very unfair.
An SFI engineer is exactly as B*Cat describes, skilled in DSL faulting.
As in any group of people though, you'll have the good, the bad and the ugly .... from fully conversant in all things DSL/Network, to new starters freshly trained. It is the luck of the draw who you would get.
An SFI engineer though, should absolutely have all the skill-sets that other engineers may only have one or two of ....... such as MDF/HDF accredited, UG accredited, OH and internal accredited ....... along with DSL accredited. In a nutshell, he/she should be able to perform any task required if a fault is found.
There's the rub .... if a fault is found. They are given strict instructions to carry out the mandatory suite of tests (agreed with all ISP's) and if they all pass, it's adios amigo. They are requested to do so as there will be other customers requiring their services.
This is why it was agreed by all involved that there is a 'cone of acceptance' with regard to the tests. If your circuit falls in that CoA, then it's job done as far as OR and your ISP are concerned. If there is a fault found internally beyond the NTE, then the engineer can repair it if it falls within the 2hr total time paid for by the ISP. If the fault is found to be on OR's network, then there is no time limit on repairing it.
Faults never mend themselves, so if it isn't found on this visit due to being miniscule and in its infancy, then over time it will degrade for sure to the point the tests will find something untoward that can be worked on.
Of course, this will cause debate but it is what it is ....... if there's a nothingness kind of fault, that only by actively searching for it would you know it was even there, chances are the SFI visit will be 20mins long.
Cone of Acceptance, ISP's agreement to the CoA ... and other fault/install volumes to deal with are to be borne in mind.
I haven't read this thread in its entirety, so unsure as to what level of service affecting issues you are currently experiencing, Weaver. :)
-
The downstream sync rate just goes steadily down and down until it lands at something less than 1 Mbps (normal downstream is 2.7 Mbps @3dB SNRM) while the downstream SNRM goes way up, currently it’s at 12 dB. The ES and CRC values are way too high as part of the sickness, normally the ES count over 15 mins is zero and I like to keep it that way. Right now the most recent downstream speed is 350 kbps. I say ‘most recent’ because the link has been down for about 20 hours and up for 3 hours before that.
Over the last week the link has been up and down for long periods repeatedly.
So I am hoping that given that there’s no DSL at all at the moment this should be a million miles outside the CoA.
OR engineer was booked to come this afternoon, but never showed so I emailed A&A.
-
The downstream sync rate just goes steadily down and down until it lands at something less than 1 Mbps (normal downstream is 2.7 Mbps @3dB SNRM) while the downstream SNRM goes way up, currently it’s at 12 dB. The ES and CRC values are way too high as part of the sickness, normally the ES count over 15 mins is zero and I like to keep it that way. Right now the most recent downstream speed is 350 kbps. I say ‘most recent’ because the link has been down for about 20 hours and up for 3 hours before that.
Over the last week the link has been up and down for long periods repeatedly.
So I am hoping that given that there’s no DSL at all at the moment this should be a million miles outside the CoA.
OR engineer was booked to come this afternoon, but never showed so I emailed A&A.
An engineers dream is that, Weaver - give me a circuit that isn't working at all, over an intermittent one any day of the millennium !! Fingers crossed for success, mate.
-
AA tell me that they have been chasing BTW re line 4 and other earlier chaos. No news yet though.
Here’s the very latest picture of horror, at 288 kbps downstream, 350 kbps upstream. Weird shape, slightly, required a small revision of the HCD detection algorithm to v5.2 to also handle this. Notice the cut-off on the right, above tone ~110. Can anyone elucidate? The normal highest tone is at ~150-160, very approximately.
(https://i.postimg.cc/5tmf9xk1/61-DB2171-D318-43-A2-B0-B0-C63-F1220-C21-D.png)
-
Notice the cut-off on the right, above tone ~110. Can anyone elucidate? The normal highest tone is at ~150-160, very approximately.
My guess is that the faultly metallic pathway is acting as a band-pass filter, only allowing a signal of limited frequency range to reach the ATU-R.
-
My guess, based on nothing much, was that it was some kind of conscious decision made by the ZyXEL when the higher tones are judged to be full of garbage and so need to be disabled. One thing in favour of this, and something that perhaps works against your metallic path theory, is that the cut-off is at a ‘significant number’ tone, here tone 110, if I’m reading it correctly. It’s a multiple of ten, and that, I think, is suspicious.
-
What happened to the SFI visit you mentioned ???
-
Regarding the SFI that never happened, AA chased BTW but I haven’t heard the verdict.
Engineer came today (thu) and ‘did some extra tests’ maybe that’s SFI? He’s just the same old engineer I’ve had many times. He said that the pair quality was superb, main electrical parameters were as expected for an ultra-long line with very thick copper (4.5 mi approx) and the two legs were perfectly matched, speed was 2 Mbps downstream @ 9dB target SNRM. The reason that it was so horrible for many days, at 288kbps downstream @ ~20dB SNRM (and that’s slower than the upstream at 350k) was that someone (OR, BTW) had capped the downstream at that lowest speed, and that made it ‘work’ albeit utterly useless. The engineer said who could have capped it? Not me said I, although I can, using AA’s controls at clueless.aa.net.uk.
It had been working ‘ok’, if you can call it that at that ultra-low speed, the DSL link was up anyway, for two days. So it seems the engineer missed the fault, came too late.
Very frustrating. We have learned absolutely nothing from this.
-
Given that our man didn’t do anything on Thursday, I supposed that I shouldn’t be surprised that the HCD fault wasn’t fixed.
It isn’t. It was just completely in hiding for a couple of days, looking 100% good. Until yesterday afternoon (Sunday). My wellness summary tool, after a bug fix or two and many performance upgrades (see other thread), picked up on the very beginning of an HCD chord 2 ‘notch’ fault - the smallest and narrowest type initially anyway.
So here we go again. :(
(https://i.postimg.cc/W487RdbN/D349184-D-6846-4-D7-A-B821-B6-CE335-D8-C84.png)
-
The US band, also, doesn't look that particularly healthy. :-X
-
Could you tell me what you see in the US ? line 4 has always had a really rubbish upstream speed, only 350 kbps, as opposed to 550-650 on the others.
-
Just as we can estimate, by eye, where the blue curve should be for the DS band, we can do likewise for the green curve of the US band. It should gracefully rise to a maximum and then, just as gracefully, decrease to its low point (sub-carrier 31). That rapid plummet, with four saw teeth, is abnormal.
-
OR was booked for Wednesday, never turned up. OR told AA that they had tried to call Janet twice and couldn’t get hold of her. That was a flat out OR lie to AA, as Janet rechecked her voice mail. Second time this has happened with OR. Rebooked for Saturday.
This morning at 10:00 UTC line 2 also failed with instant bad HCD. About 6dB depth in an instant. Very unusual not to get a slow growth development, with lots of warning. So now two lines very bad at the same time.
-
:o :(
-
Spotted thanks to my wellness summary program, which detects HCD. As I mentioned before though, the problem is that I only run it by hand - it’s not observing the modems continuously. A port to DLang on the Raspberry Pi would mean that I could get an alert, perhaps by email. I would have to have the energy for such a big job though. Need regex and text processing libraries, which exist already and would need an https library too, not sure about that, would have to check. Not sure about timer operations. I would really want asynchronous i/o with events, and iowait multiplexing (wait on OR of asynchronous io and timers) Everything just now is with synchronous waits, but that makes it vulnerable to modem hang failure, which is no good in a server unless you were to make the whole thing multithreaded and that introduces a whole lot of entirely unnecessary complexity. Mind you, since there are n modems, parallel computation of the many regex operations that it performs would be nice on a multi core cpu.
-
Wellness summary, right now. Note that line 4 has been disabled as it was causing so much trouble, so it doesn’t show up in the following report:
Summary of DSL links’ wellbeing and error counts
────────────────────────
* There are 4 modems in total. They are: #1, #2, #3 and #4
* The active, contactable modems are: #1, #2 and #3
* The modem skip-list declared in config: #4 was skipped over and not queried; its state is unknown
* The modems successfully queried are: #1, #2 and #3
───────────────────────
*** ***
*** There is some SERIOUS BADNESS ! ***
*** All is not well ! 😦 ***
*** ***
───────────────────────
*** Note that modem #4 was skipped over and not queried; its state is unknown.
*** This may be because (i) the modem is turned off, or (ii) is not connected, or (iii) is the wrong
*** model, (iv) has not been configured, (v) is in the wrong 'slot', (vi) is configured for the wrong
*** slot, or (vii) does not contain the required Johnson ZyXEL custom software. ***
* Sync rate: The following link has a really low downstream sync rate, below min:
Link #2 downstream: current sync rate 742 kbps is below minimum expected downstream rate (2600 kbps)
--
* SNRM: The SNRM of the following link is out of range:
Link #2 downstream: current SNRM: 11.6 dB is too high; above the expected maximum SNRM ( 3.8 dB )
--
* HCD:❗So-called ‘hollow curve disease’ (HCD) defect detected in the downstream SNR-vs-tones curve of link #2. Serious fault. 🔺
Link #2: Summary: curve midpoint test tone 59 is 6.89583 dB below chord 1: (tones 40-88); ❗
Link #2: Details: chord 1: [ tone 40: 26.4375 dB; chord midpoint test tone 59: 26.83333 dB; tone 88: 27.4375 dB ]; curve midpoint test tone 59: 19.9375 dB
◅ ◅ ◅◊▻ ▻ ▻
Here’s the horror that is line 2:
(https://i.postimg.cc/fR3qgRpp/DC891-EAB-F8-A6-47-AC-B94-A-FD3099-BE09-A6.png)
Line 4, not very up to date:
(https://i.postimg.cc/VLMcHwT7/28490694-BB8-D-4165-B6-BB-24746-B50-B662.png)
-
Hmm . . . It almost looks as if the haggis have something against your even numbered devices!
Modem #4 appears to have the disease at its worst.
-
Modem #4’s ‘void’ going to zero in the middle is really new. Horrible. I haven’t looked at it all week as it has been unplugged because its downstream error rate was so high even on max SNRM.
-
If you still have the original, raw, data from modem #4 available it would be interesting to examine it.
The output, generated in response to the following commands (no post-harvest editing / modification, please) --
xdslctl info --stats
xdslctl info --SNR
xdslctl info --QLN
xdslctl info --Hlog
xdslctl info --Bits
xdslctl info --pbParams
You know the e-mail address to which it could be sent. :)
-
I’m afraid I have now lost the opportunity, in respect of line 4, at any rate.
OR engineer came today, said he was only booked to look for telephony faults, went away. Line 4 now looks excellent so could this be one of those ‘mystery fixes’? Or did the fault just go away on its own during the week that I had it unplugged? (Because the high error rate was causing problems for the whole bonded set.) Rather than unplugging the modem from the router, I’m wishing now that I had just disabled the line at AA’s end so that I could have carried on monitoring the modem. The DSL link should have been in the showtime state for the whole of that week if it was feeling well enough, and I didn’t do anything to ‘cure’ it at this end at all.
-
I'm sure that, eventually, there will be another opportunity.
-
Amazing development: after almost exactly 24 hours (hmm) line 2 has fixed itself. The HCD has gone away! The slightest trace of it may be detectable to the keen eye, but it doesn’t satisfy the criterion required by my summary program to be reported as HCD. Its ’depth’ if any is probably less than 1 dB, judged by eye, so that is counted as ‘in the noise’ and not deemed suitable for a reliable warning report.
(https://i.postimg.cc/yxpB3DxH/936-AA856-9-C97-4296-AC58-42-C3-C0-FBFDD2.png)
-
How odd. Could it be something environmental is taking place? (b*cat is puzzled.) ???
-
I just can’t think what a candidate cause might be. If it had started at exactly 11:00 then that would be very interesting, but iirc it was around 10:55. And it was very close to 24 hours’ duration. I’m befuddled here; could it have been a limited-band interference blast lasting 24 hours? And just covering those tones roughly 45-80 or probably a bit narrower than that.
I have now finally done what I’ve been wanting to do for ages; I’ve moved the code around in my modem wellness summary program and reordered the HCD per-chord tests so that they are now in the order: test chord 1, then chord 2, then chord 3. I immediately introduced a bad bug, false error report with chord 1. This was because when trying to move statements around by dragging, the Shortcuts code editor dropped a moved statement in completely the wrong place, and the editor seems to allow variables to be used before values are assigned to them. So simply moving the variable definition down to where it should be fixed the bug. The computed value of the y coordinate of the (approx) midpoint or test-point of the chord 1 diagonal line was very obviously wrong, and it turned out that this was caused by the use of the undefined variable, the x-coordinate of the midpoint, in the equation of a straight line, whose value was I think defaulting to zero.
Janet has just pointed out something very significant, which I had forgotten about. The line went down at Fri 10:55:22 and (as best I can tell, because there was a lot of chaos in the log) came back up at Sat 10:56:33. So pretty close to 24 hours. But that up-time was during the time period the OR engineer was investigating line 4. So that is suspicious. Mind you, he was supposed to be working on line 4, not line 2.
-
Janet has just pointed out something very significant, which I had forgotten about. The line went down at Fri 10:55:22 and (as best I can tell, because there was a lot of chaos in the log) came back up at Sat 10:56:33. So pretty close to 24 hours. But that up-time was during the time period the OR engineer was investigating line 4. So that is suspicious. Mind you, he was supposed to be working on line 4, not line 2.
Ah, ha! That is interesting. Assuming all four of your lines are in the same cable, which is very likely to be the case, opening a joint closure and poking the contents with an Openreach magic-wand could perturb all of the pairs in the cable. (Now if the joint being worked upon was back up on the high moor and the engineer left the joint in an open state, whilst getting some gubbins from the back of his van, an evil haggis could have pee'd in the joint without being noticed.)
-
Janet told me that the engineer just tested line 4, told us both the results and left without going out onto the high moor to fix anything. This was because it looked all good, having got mysteriously fixed by who knows what mechanism as has often been observed, and because her was only booked to do ‘telephony’-type work, and told Janet something about a menu of job prices for different activities, something which I couldn’t hear. He said that he had been told that the line had crackles on it, and put this ‘end-user reported crackles’ in his notes that were sent back to AA. This was an outright lie from someone; I certainly never said any such thing, not even having a phone plugged in. One of my favourite sayings: “Mas breug bhuam, bu bhreug chugam e” - if it is a lie from me, it was a lie to me. I don’t like the fact that someone is saying that we said things that we did not. Very odd.
-
Line 2 current picture:
(https://i.postimg.cc/4dd1D6wS/8-E3-C392-F-910-D-49-A4-94-D7-97-C98-FB808-D8.png)
The line 2 HCD depth or ‘drop’ has now increased to 2.16 dB. Still not enough to cause any major problems, but the error rate is now non-zero.
Summary of DSL links’ wellbeing and error counts
────────────────────────
* There are 4 modems in total. They are: #1, #2, #3 and #4
* The active, contactable modems are: #1, #2, #3 and #4
* The modems successfully queried are: #1, #2, #3 and #4
───────────────────────
*** ***
*** There is some SERIOUS BADNESS ! ***
*** All is not well ! 😦 ***
*** ***
───────────────────────
* HCD:❗So-called ‘hollow curve disease’ (HCD) defect detected in the downstream SNR-vs-tones curve of link #2. Serious fault. 🔺
Link #2: Summary: curve midpoint test tone 59 is 2.15938 dB below chord 1: (tones 40-80); ❗
Link #2: Details: chord 1: [ tone 40: 35.0625 dB; chord midpoint test tone 59: 33.22188 dB; tone 80: 31.1875 dB ]; curve midpoint test tone 59: 31.0625 dB
--
* ES (not so serious): The following links have a few CRC errors, at lower error rates, where the ES rate < 60 ES / hr (†):
Link #2: downstream: most recent period: ES per hr: 32.00, mean time between errors: 112.5 s, collection duration: 450 s, SNRM: 2.399 dB
Link #2: downstream: penultimate period: ES per hr: 12.00, mean time between errors: 300 s, collection duration: 900 s, SNRM: 2.399 dB
◅ ◅ ◅◊▻ ▻ ▻
-
Latest analysis. The error rate has really picked up, so I will have to adjust the downstream SNRM now. This is before any such adjustment.
Summary of DSL links’ wellbeing and error counts
────────────────────────
* There are 4 modems in total. They are: #1, #2, #3 and #4
* The active, contactable modems are: #1, #2, #3 and #4
* The modems successfully queried are: #1, #2, #3 and #4
───────────────────────
*** ***
*** There is some SERIOUS BADNESS ! ***
*** All is not well ! 😦 ***
*** ***
───────────────────────
* HCD:❗So-called ‘hollow curve disease’ (HCD) defect detected in the downstream SNR-vs-tones curve of link #2. Serious fault. 🔺
Link #2: Summary: curve midpoint test tone 59 is 1.78716 dB below chord 1: (tones 43-80); ❗
Link #2: Details: chord 1: [ tone 43: 35.3125 dB; chord midpoint test tone 59: 33.47466 dB; tone 80: 31.0625 dB ]; curve midpoint test tone 59: 31.6875 dB
--
*❗ES (serious): Links with CRC errors at higher error rates, where the ES rate ≥ 60 ES / hr (†):
Link #2: downstream: most recent period: ES per hr: 65.78, mean time between errors: 54.73 s, collection duration: 602 s, SNRM: 2.399 dB
Link #2: downstream: penultimate period: ES per hr: 64.00, mean time between errors: 56.25 s, collection duration: 900 s, SNRM: 2.399 dB
--
* ES (not so serious): The following link has a few CRC errors, at a lower error rate, where the ES rate < 60 ES / hr (†):
Link #1: upstream: penultimate period: ES per hr: 48.00, mean time between errors: 75 s, collection duration: 900 s, SNRM: 5.799 dB
────────────────────────────────────
(†) The duration of a most ‘recent’ errored seconds (ES) collection bucket is
variable, with a _maximum_ of 15 mins. The ‘most recent’ buckets’ start times
are always 15 mins apart. A ‘penultimate’ bucket is a fixed 15 mins. An ES is a 1 s
time period during which corrupt data is received by a DSL modem that not be
recovered by the error correction methods of the two DSL modems. (This is not
to be confused with the error recovery method used in ‘transport layer’ software
such as QUIC, TCP etc that uses whole-path, end-to-end packet retransmission.
Here we are only concerned with error recovery over one single DSL link.)
────────────────────────────────────
◅ ◅ ◅◊▻ ▻ ▻
-
Here’s a recent picture of line 2, Thursday morning 2022-09-08T09:20:
(https://i.postimg.cc/KjDFpwsJ/A382-C140-2-B32-4565-ADEA-1-F20-A2-F01-A94.png[)
And then, an amazing spontaneous recovery, Thursday afternoon 2022-09-08 when there was a period of instability, with many retrains including one where the downstream sync rate dropped quite low, maybe to something like 1.4 Mbps. Then the downstream sync rate came right back up to roughly where it should have been and the HCD was completely gone.
(https://i.postimg.cc/V6nQVpH2/898-E3220-EB42-40-D6-A1-D1-88-C9619-DF279.png)
This is the summary of wellness of all lines after I put the line 2 downstream target SNRM back to 3 dB. It isn’t happy with that target at all as you see. So I shall go back to line 2 6 dB downstream target SNRM, and adjust config expectation settings accordingly. But otherwise all is good.
Summary of DSL links’ wellbeing and error counts
────────────────────────
* There are 4 modems in total. They are: #1, #2, #3 and #4
* The active, contactable modems are: #1, #2, #3 and #4
* The modems successfully queried are: #1, #2, #3 and #4
───────────────────────
*** ***
*** There is some SERIOUS BADNESS ! ***
*** All is not well ! 😦 ***
*** ***
───────────────────────
*❗ES (serious): Links with CRC errors at higher error rates, where the ES rate ≥ 60 ES / hr (†):
Link #2: downstream: most recent period: ES per hr: 60.10, mean time between errors: 59.9 s, collection duration: 599 s, SNRM: 3.10 dB
────────────────────────────────────
(†) The duration of a ‘most recent’ errored seconds (ES) collection bucket is
variable, with a _maximum_ of 15 mins. The ‘most recent’ buckets’ start times
are always 15 mins apart, and the end time is now. A ‘penultimate’ bucket is a
fixed 15 mins long. An ES is a 1 s time period in which a DSL modem receives
corrupt data that can not be recovered by the two modems’ error correction
capabilities. (This is not to be confused with the whole-path, end-to-end packet
retransmission-based error correction used in ‘transport layer’ software such as
QUIC, TCP etc. Here we are only concerned with data corruption on a single,
direct, modem-to-modem DSL link, and its correction by modems.)
────────────────────────────────────
◅ ◅ ◅◊▻ ▻ ▻
Here are the full stats for all lines just now:
Status of each link
──────────
* There are 4 modems in total. They are: #1, #2, #3 and #4
* The active, contactable modems are: #1, #2, #3 and #4
* The modems successfully queried are: #1, #2, #3 and #4
Link #1: sync rate: downstream: 2.641 Mbps at SNRM 2.9 dB; upstream: 646 kbps at SNRM 5.8 dB
Link #1: uptime: 15 days 20 hours 44 min 39 sec
--
Link #2: sync rate: downstream: 2.684 Mbps at SNRM 3.1 dB; upstream: 515 kbps at SNRM 6.2 dB
Link #2: uptime: 1 hour 3 min 27 sec
--
Link #3: sync rate: downstream: 2.968 Mbps at SNRM 3.1 dB; upstream: 627 kbps at SNRM 5.6 dB
Link #3: uptime: 13 days 10 hours 57 min 47 sec
--
Link #4: sync rate: downstream: 2.741 Mbps at SNRM 3.1 dB; upstream: 355 kbps at SNRM 5.8 dB
Link #4: uptime: 5 days 2 hours 27 min 27 sec
◅ ◅ ◅◊▻ ▻ ▻
-
I suspect there is a less than perfect joint somewhere along the vastness of your lines and that weather or other variable conditions are affecting it.
Always a pain to find when intermittent like this.
-
This latest plus, last Saturday’s are the only two so-far known instances of spontaneous recovery, without some kind of at least possible engineer intervention in the form of a visit, even though it is not known what action or effect the visits have had.
-
Yesterday we should have had an SFI about HCD (900 kbps downstream) in line 2. No show, again, no phone call.
-
Line 2 is bad again, and line 4 is showing the very faintest sign of HCD on the threshold of reliable detection.
There were two (!) Openreach no-shows last week for SFI appointments. That makes three or maybe four no-shows. AA has escalated it within BT and I’m leaving them to it. They are asking BT what’s up with the absent engineers and also, I hope, asking what the plan is to get my line 2 finally fixed for good. I’m once again thinking about getting an additional line and then ceasing this one.
Line 2 suddenly became perfect in the middle of the illness and then jumped straight back to badness after two days of being fine. So now it’s becoming more intermittent, which is a new development.
Down to 288 kbps downstream at 12 dB SNRM, upstream is fine.
FYI The new line line 3 is 3.048 Mbps downstream sync @ 3dB target SNRM and literally zero ES/CRCs, and the upstream is good at 630 kbps @ 6dB. So it shows you what it could be like.