DLM fault recovery

Thanks for the great discussion on my previous thread about the effect of E side cable faults on D side VDSL performance!

I didn't cancel the appointment and the Openreach engineer came yesterday and replaced some very old down 2-core downlead that had been left in-situ due to the addition of a porch on our house. Fingers crossed that was the cause of the line noise which, although intermittent, hasn't come back despite todays rain (yet!).

Now i'm starting the long path to linespeed recovery. My downstream profile had dropped from historic highs of 69Mbps+ to 52.72Mbps and stuck; after 1 day unsurprisingly it is still stuck there.

However, I have noticed that my upload throughput , which had dropped from 17.06 to 16.21 at the same time has just jumped back to 17.06 (TBB SpeedTest).

These upload figures usually hardly vary in value, so am I right in thinking interleaving has been reduced, at least on the upstream? Is that controlled by the modem rather than by the MSAN?

When do people typically start to see the Download profile being upped after a fault fix?

Cheers.

My fault caused a 75% speed drop. After the line was fixed mine fully recovered in stages over the following 10 days.

I used Thinkbroadband's BQM to keep an eye on what was happening and I would occasionally see some packet loss at 4am accompanied by a change in latency (visible on the graph) or a speed boost.

There was no need to restart either the router or Openreach modem - it all just happened.

Good luck!

Edited by Neken (Fri 24-May-13 00:22:34)

In reply to a post by Colin_London:

These upload figures usually hardly vary in value, so am I right in thinking interleaving has been reduced, at least on the upstream? Is that controlled by the modem rather than by the MSAN?

They happen during sync negotiation, but it is hard to say which end actually determines what interleaving/FEC setting gets used.

DLM usually puts requirements on the sync process, specifying the INP protection needed, and the acceptable delay in interleaving.

However, we've seen cases where the sync process has resulted in FEC being turned on upstream, without interleaving and without any apparent requirement from DLM.

Perhaps you are seeing an adjustment in that area.

Otherwise a TBB BQM will help see changes in latency, as would an f8lure graph.

I took my FTTC line about 3 weeks to get back to full speed after a fault.

I didn't cancel the appointment and the Openreach engineer came yesterday and replaced some very old down 2-core downlead that had been left in-situ due to the addition of a porch on our house. Fingers crossed that was the cause of the line noise which, although intermittent, hasn't come back despite todays rain (yet!).

Not the E-side then ?

what was fixed on the line? and did it pass jdsu tests with the speed drop?

Well I was tempting fate posting this thread. After the rain last night the noise is back

So it's going to be a problem between the pole and the cab.

Back to trying to call them out after a rainstorm.....

My NTE had suffered corrosion resulting in no dial tone and massive crackling on incoming calls so it was replaced. I don't know the details of the tests, sorry.

I've been logging recovery since a drop from experimenting with HG622, and was going to post when it was fully recovered.

Text

1 23 45 67 89 1011 1213 1415 1617 1819 2021 2223 2425 2627 2829 3031 3233 3435

~~~ 14 May  Put back in HG612, but stats still based on DLM with 622.~~~                 Down            Upmax:            82556          23845 path:           53289          18115SNR (dB):        9.3             6.2 delay:          8.00            7.00  ~~~17 May ~~~                Down            Up max:            82812          22166path:           59998          20000  <<< upload back to full: 18.5 Thinkbroadband SNR (dB):        7.8             7.0delay:          10.00           0.00  ~~~ 22 May~~~                 Down            Upmax:            82664          22001 path:           63263          20000SNR (dB):        6.4             7.0 delay:          9.00            0.00  ~~~23 May ~~~                Down            Up max:            82900          22081path:           66998          20000 SNR (dB):        6.9             7.1delay:          8.00            0.00

Still not complete (I hope): my downstream sync was 74156 before the disruption.
It seems that upstream does not nearly so often get interleaved, and recovers quicker.
My max upload speed is 18.5Mbps; was 17Mbps before I turned off QoS on the modem.

Good luck with getting rid of your noise completely.

There is a dampening sub-function to the re-profiling component of the DLM algorithm - to prevent oscillation or "churn". Churn was a deficiency of earlier DLM algorithms. It is where a DSL repeatedly re-grades upwards and then downwards, due to minor variations in line conditions. The churn occurs in a never-ending cycle, and introduces instability of its own (unnecessary re-syncs).

This dampening effect is more pronounced when moving up to a more "aggressive" profile (i.e. to higher data rate and/or lower interleaving/INP), than when re-profiling down to a less aggressive one (i.e. a lower data rate and/or higher interleaving/INP).

In other words, the DLM takes somewhat longer to re-profile upwards than it does to re-profile down.

BT has a number of patents describe its DLM algorithms, some dating to 2007, if not earlier. There is a smattering of pseudo-code in the patents that document the dampening effect.

In later patents the inventors describe a variable sample rate. Seriously defective lines are identified separately, according to error counts and retrains per sample period. These lines are then sampled at greater frequency than ones showing stability in the past. Eventually if downwards re-profiling still doesn't resolve the instability, a poor line is flagged up for engineer's inspection.

The typical DLM sample rate is reportedly every 15 minutes (a DLM "timeslot"). And there are 96 of those in a 24 hour period.

Various efforts are made to identify "area-wide events". These events cause a batch of line re-syncs at the same aggregation transceiver device, or geographically-neighbouring devices. An obvious example is a thunderstorm. These transient events should be excluded from the DLMs dataset used for re-profiling.

Attempts are also made to identify user-initiated re-syncs, so that they too do not cause unnecessary re-profiling. Some devices, e.g. those based on the Broadcom BCM63xx chipset support a "Dying Gasp" when power is pulled. This is a final G993.2 message to inform the DSLAM that there has been a power failure at the CPE. This is used to distinguish the re-train from an automatic or forced re-train due to deteriorating line conditions.

Cheers, a

P.S. Patents for BT's DLM algorithms include EP2342902B1, EP2169980A1, US2012/0099424

[1] https://data.epo.org/publication-server/pdf-document...
[2] https://data.epo.org/publication-server/pdf-document...
[3] http://patentimages.storage.googleapis.com/pdfs/US20...

Edited by asbokid (Fri 24-May-13 17:20:48)