Print

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

[Weaver]

There has been a sudden outbreak tonight, second in two days, same modem: turned off, but perhaps not for long enough. The first power-cycling seemed to fix matters perfectly but it only lasted 24 hours.

[burakkucat]

Just how long was the device left in a powered-off state?

Seconds? Minutes? Or an hour?

[Weaver]

Janet left it switched off for less than two minutes last night and one minute tonight very rough guess, she wanted to get to her bed. Didn’t work tonight at all.

[burakkucat]

Hmm . . . In that case, I will suggest 15 - 30 minutes should be tested, next time.

[Weaver]

The main hollow tonight was very pronounced during the second outbreak, with loss of 800 kbps down to 2.1Mbps downstream, then loss of 1.5Mbps down to 1.4 Mbps downstream. After second switch-off tonight, left modem #2 off for one hour, now all good.

[Weaver]

And again. A superb result for the hcd detector which detected very early disease development. Disappointing that modem 2 only stayed healthy for about 12 hours or so though after a hard reset. Really will have to replace modem 2.

—
    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 !   😦                                ***
       ***                                                                           ***
       ───────────────────────


--
* SNRM: The SNRM of the following link is out of range:
   Link #2 downstream: current SNRM:  1.9 dB is too low; below the expected minimum SNRM ( 2 dB )

*❗Link #2 defect detected: so-called ‘hollow curve phenomenon’ in the downstream bit-loading 🔺

--
* ES (less serious): The following links have a few CRC errors, at lower error rates, where the ES rate < 60 ES / hr (†):
   Link #1  upstream:            latest period: ES per hr:   9.18, mean time between errors: 392 s, collection duration: 784 s
   Link #2 downstream:        latest period: ES per hr:   4.04, mean time between errors: 891  s, collection duration: 891  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.
──────────────────────────────      
                                              ◅ ◅ ◅◊▻ ▻ ▻

—

Despite the ‘hollow’ being only slight, it was detected to the rhs of the centre of the region.

[burakkucat]

Despite the ‘hollow’ being only slight, it was detected to the rhs of the centre of the region.

Ah, yes. There it is, just starting to "ripen". 

[Weaver]

Taking readings for chord 1 from the above picture, my calculations show that there should indeed be an HCD=true result as the graph at x=60 is indeed just below the y value of chord1 at the test point, x=60. The graph is just under y<35.0 at x=60 and the chord chord1 at x=60 is definitely somewhat >35.0, so there is a drop from the chord chord1 to the graph at x=60.

Turning now to the latest graph, shown below, the relevant chord, chord1, is from (40, 36.4375) to (85, 32.0625) and the test is the drop from this chord at x=60. This graph is later than that shown in the picture above, readings taken at ~18:40. The graph should be below that x=60 point (60, y6) in order to trigger a true HCD result. My calculator says that the chord chord1 at x=60 is at y=34.93. Could you check that from the equation of the straight line chord 1?

Reading the values of the latest graph, the graph is seen to be y= 31.8125 at x=60, so that is indeed below the chord chord1, and so gives an HCD=true result.
 

Latest picture:

[Weaver]

I have tweaked chord2 slightly so that it runs from x=40 to x=62 instead of to 60, and the associated midpoint test for chord 1 is moved from 60 to 62 as well to still match. The reason is that the chord2 x_rhs = 62 seems to suit recently seen ‘notch’-type nascent HCD phenomena slightly better than x_rhs=60.

    /* ALGORITHM IV.2 */
    const double SNR[ 256 ];
    alias y = SNR;
    const uint half_width = 3;
    const double min_stalactite_height = 2.0;
    const double chord2_notch_min_height = 1.5; /* adjustment of sensitivity of ‘notch’-detector, detector for smaller hollow in chord2 x=40 to x=62 */

    const bool y40_is_bogus = y[40] < y[40 + half_width] - min_stalactite_height;
    const uint x4 = y40_is_bogus ? 40 + half_width : 40;
    const double y4 = y[x4];
   
    const bool y5_is_bogus = (y[52] < y[52 - half_width] - min_stalactite_height )
                          && (y[52] < y[52 + half_width] - min_stalactite_height );
    const uint x5 = y5_is_bogus ? 52 + half_width : 52;
    const double y5 = y[x5];

    const bool y62_is_bogus = (y[62] < y[62 - half_width] - min_stalactite_height )
                           && (y[62] < y[62 + half_width] - min_stalactite_height );
    const uint x6 = y62_is_bogus ? 62 + half_width :  62;
    const double y6 = y[x6];

    const bool y85_is_bogus = (y[85] < y[85 - half_width] - min_stalactite_height)
                           && (y[85] < y[85 + half_width] - min_stalactite_height);
    const uint x8 = y85_is_bogus ? 85 + half_width : 85;
    const double y8 = y[x8];

    /* line chord1 [(x4,y4)-(x8,y8)]; 'approx midpoint' is at (x6, ymid1); data point is at (x6, y6) */
    const double ymid1 = y4 + ((y8 - y4)*(x6 - x4))/(x8 - x4); /* fp div required */
    const bool hollow_curve1 = y6 < ymid1;
   
    /* line chord2 [(x4,y4)-(x6,y6)]; 'approx midpoint' is at (x5, ymid2); data point is at (x5, y5) */
    const double ymid2 = y4 + ((y6 - y4)*(x5 - x4))/(x6 - x4); /* fp div required */
    const bool hollow_curve2 = y5 < ymid2 - chord2_notch_min_height;

    const bool hollow_curve = hollow_curve1 || hollow_curve2;

[burakkucat]

I haven't "single-stepped" through your latest code but looked at where you have made the latest change. It looks good. 

[Weaver]

The new rhs x parameter seems to catch the top of the rhs better; before it wasn’t up to the top of the peak, was too far to the left of it still.

[Weaver]

Referring to a post in a recent thread elsewhere
    https://forum.kitz.co.uk/index.php/topic,26851.msg451815.html#msg451815

I was wondering about (i) whether anyone may have seen this elsewhere and (ii) musing on the likely impossibility of translating these ideas into VDSL2. Could someone post an SNR vs tones graph for a VDSL2 circuit?

[burakkucat]

Could someone post an SNR vs tones graph for a VDSL2 circuit?

I have sent an e-mail message direct to you (at "The Weaving Shed") with eight such plots as an attachment. 

[Weaver]

I think we would have to define some terms. A wider definition might be "frequency-selective SNRM decrease". That doesn’t say as much about shape, so I think it’s weaker, but it concentrates on the essentials, that here we have a phenomenon limited to a frequency range.

[Weaver]

There has been a recent additional HCD case, line 4, see https://forum.kitz.co.uk/index.php/topic,27118.0.html and the HCD detector sometimes did successfully detect and report HCD, sometimes not, as the fine details kept shifting and this was a shape not seen before (see above link).

To handle this new shape, I added a third chord test, one with a right-hand (max x) end value of 70 in addition to the earlier chord 1 test that had a rhs at around tone 80. The tone range of this chord then is 4x - 70, where 4x is a bit greater than 40m adjusted for stalactite detection. I have not yet put in stalactite detection at the rhs tone 70 end, as there does not seem to be much of a problem yet. I will probably have to add that further enhancement / tweak for increased robustness.

So this gives us algorithm V.0 which now has a triple test: is_hollow_chord1 || is_hollow_chord2 || is_hollow_chord3.

With this new chord, the algorithm V.0 picks up the HCD nicely. It’s because the rhs endpoint is now on the rh mound, local maximum, so just nicely to the right of the local minimum that we’re interested in finding, the drop below the chord’ midpoint-y.



This is the problem picture.

[Moderator edited to fix a typo in a markup tag.]