General Discussion
  >> Fibre Broadband


Register (or login) on our website and you will not see this ad.


Pages in this thread: 1 | 2 | (show all)   Print Thread
Standard User Colin_London
(member) Fri 24-May-13 00:10:25
Print Post

DLM fault recovery


[link to this post]
 
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.
Standard User Neken
(knowledge is power) Fri 24-May-13 00:20:34
Print Post

Re: DLM fault recovery


[re: Colin_London] [link to this post]
 
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!

__________________________________________________________
How can one little insulated wire bring so much happiness! - Homer Simpson

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

Standard User WWWombat
(fountain of knowledge) Fri 24-May-13 00:33:54
Print Post

Re: DLM fault recovery


[re: Colin_London] [link to this post]
 
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.


Register (or login) on our website and you will not see this ad.

Standard User Alex1M6
(regular) Fri 24-May-13 03:00:45
Print Post

Re: DLM fault recovery


[re: Colin_London] [link to this post]
 
I took my FTTC line about 3 weeks to get back to full speed after a fault.
Standard User Zarjaz
(knowledge is power) Fri 24-May-13 06:54:02
Print Post

Re: DLM fault recovery


[re: Colin_London] [link to this post]
 
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 ? smile

Standard User Chrysalis
(legend) Fri 24-May-13 08:14:02
Print Post

Re: DLM fault recovery


[re: Neken] [link to this post]
 
what was fixed on the line? and did it pass jdsu tests with the speed drop?

BT Infinity 2 Since Dec 2012
Standard User Colin_London
(member) Fri 24-May-13 08:43:08
Print Post

Re: DLM fault recovery


[re: Neken] [link to this post]
 
Well I was tempting fate posting this thread. After the rain last night the noise is back frown

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

Back to trying to call them out after a rainstorm.....
Standard User Neken
(knowledge is power) Fri 24-May-13 09:08:07
Print Post

Re: DLM fault recovery


[re: Chrysalis] [link to this post]
 
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.

__________________________________________________________
How can one little insulated wire bring so much happiness! - Homer Simpson
Standard User StephenTodd
(experienced) Fri 24-May-13 09:19:03
Print Post

Re: DLM fault recovery


[re: Colin_London] [link to this post]
 
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.

--
Moved (with trepidation turned relief) to BT Infinity 2 for upload speed. Happy BE user for several years.
Standard User asbokid
(member) Fri 24-May-13 13:20:29
Print Post

Re: DLM fault recovery


[re: Alex1M6] [link to this post]
 
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)

Pages in this thread: 1 | 2 | (show all)   Print Thread

Jump to