Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Black Sheep]

What happened to the SFI visit you mentioned

[Weaver]

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.

[Weaver]

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.

[burakkucat]

The US band, also, doesn't look that particularly healthy. 

[Weaver]

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.

[burakkucat]

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.

[Weaver]

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.

[burakkucat]

  

[Weaver]

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.

[Weaver]

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:



Line 4, not very up to date:

[burakkucat]

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.

[Weaver]

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.

[burakkucat]

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. 

[Weaver]

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.

[burakkucat]

I'm sure that, eventually, there will be another opportunity.