DLM - "What it is and how it works"

This is the most comprehensive ISP document I've come across so far regarding FTTC DLM (from Plusnet): FTTC DLM - What it is and how it works

Can people say how accurate they think this is?

I thought this was an interesting statement:
"Any changes made by DLM are executed between 3am-5am"

I would say the 3-5am statement is wrong. Every DLM intervention I've had has come at 8:01am.

Are you sure that was DLM intervention and not a broken VDSL connection; eg from a big burst of noise.

Pretty sure my interventions have happened between midnight and 7am.

If DLM finds that your line is erroring enough to cause the quality of your service to become poor, it will act and either apply Interleaving or reduce the �speed band� that you�re set within.

I'm sure many will argue that this is often not the case and that DLM is far too quick to make changes that add lag and slow speeds,based on error rates,It often intervenes where is doesn't need to
In other words what it considers to be above normal error rates may not be noticeable to the end user, and if left they may never do so, the errors are often not enough to cause problems with throughput or instability. dlm is triggered way before the line is actually impacted

Edited by tommy45 (Mon 06-Oct-14 15:38:52)

In reply to a post by tommy45:

In other words what it considers to be above normal error rates may not be noticeable to the end user, and if left they may never do so, the errors are often not enough to cause problems with throughput or instability. dlm is triggered way before the line is actually impacted

It depends what you are doing with the data.

If everything is transferred under a protocol that notices the failure and gets a re-transmission, such as TCP (used by downloads) then you'll just get a drop in throughput. If the error rate gets high enough, the throughput drops dramatically, but for more normal error rates, you'll barely notice the difference.

If, however, it is transferred under a protocol that does not re-transmit, you just get gaps in the transmission. For most people, this happens to the protocols used for streaming audio & video, and for online gaming. As the error rate increases, the gaps become more noticeable (and, for streaming, the glitches they cause to the audio and video become more intolerable). Any errors here are noticeable to the eye and ear, even if they don't cause you to miss the plot. We humans are rather less tolerant of these errors than a computer is to a re-transmitted packet.

Under FTTC, DLM is undoubtedly tuned so as to give a good experience for streamed video - and particularly to make sure that subscription TV gets somewhere close to broadcast quality. That means it has a lower tolerance to errors than would be needed for "just" downloading.

But not everyone has an internet connection in order to watch tv, that imo isn't what the internet is for, though if government has it's way it will become just for that and a platform for it's own uses ,

Did adslmax see any issues streaming tv or you tube videos prior to dlm kicking in? even if he did see buffering it doesnt necessarily mean it was due to an increased error rate, as buffering can be caused by a number of other things, even software for instance the ff add-on "you tube HD" that would cause almost all you-tube video streams to stop at 14 seconds from the start then there is network congestion, to and from and including the CDN it's self

If the info about the error rates that he posted are factually correct and not misreported in any way by the modem in use , i wouldn't consider the figures excessive or likely to adversely impact his connection in any way as the majority of connections on Fast Path will generate some errors it's that fact that BT OR's DLM parimiters are far too sensitive ,and are causing missery too many that isnt really nescercary, by using interleave and INP to mask what they should be fixing(underlying line fault,crosstalk,ect) if they are really that concerned about providing quality

Edited by tommy45 (Mon 06-Oct-14 17:53:56)

I dont think its too sensitive on error counts but it programmed badly.

e.g. it reacts "after the event" so if you get 400k CRC for a 20 min period at 7.45pm whilst streaming eastenders, DLM doesnt react, but instead wait until the next early morning. Which if its a one off event is too late.
It seems to have little intelligence if the need to adjust the line is long term or not.

I would handle DLM like this.

If ES or UAS goes over 15 min threshold, adjust the line parameters immediately.
Set the recovery period for 24 hours for each day the events reoccur. So if the threshold is only breached for one day, 24 hours later the line is reverted, however if its 2 days in a row, then it needs 48 hours of green status before it can be reverted and so on.
Add a gaming mode, in the gaming mode, banding takes priority over interleaving if adjustments needed.

Edited by Chrysalis (Mon 06-Oct-14 18:28:44)

My DLM was resync at 8:56am on the Saturday and again last night at 2:33am. From 79999k to 72000k and now at 67000k

Edited by adslmax (Mon 06-Oct-14 19:48:01)

Are those exact numbers, or the nearest "000"?

In reply to a post by RobertoS:

Are those exact numbers, or the nearest "000"?

nearest from 001 to 999

Edited by adslmax (Tue 07-Oct-14 00:18:32)

You'll just have to cut all the other lines from your cabinet .

In reply to a post by RobertoS:

You'll just have to cut all the other lines from your cabinet .

Good thinking! Only if I have the Cabinet key!

My latest stats

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 4
Max: Upstream rate = 27134 Kbps, Downstream rate = 83177 Kbps
Path: 0, Upstream rate = 19999 Kbps, Downstream rate = 66193 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.4 12.1
Attn(dB): 0.0 0.0
Pwr(dBm): 12.4 -0.4

I think that DLM works ok, but reacts to quickly to non line faults like power cuts and modem switch offs [some people like to turn everything off at night and during away from home periods].
Also the circuits in the cabs [including the DLM boards] are prone to interference from within the cab, like from badly shielded transformers and fans etc.
It needs better shielding and re-programing imo.?

Edited by deleted (Tue 07-Oct-14 00:46:23)

An example of it's bad programing is this IMO from Zen's KB

In reference to support.zen.co.uk/kb/KnowledgebaseArticle.aspx?articleid=11511:

What are the DLM thresholds?

Zen Internet provides our Fibre Optic Broadband (FTTC) services on the �Speed� option. A connection should drop no more than 20 times in a 24 hour period, and should error no more than 2 times per minute.

over 2 errors per minute and it can baulk your connection, even though the error rate may not be high enough to be service affecting example could be upto 5-10 per min or 30, per min, But what isn't clear is for how many minutes does this tiny threshold need to be breached for in any 24hrs period before the trigger happy dlm chimes in?
As your connection may suffer from the occasional burst of errors so is dlm going to act because a line had a increased error rate over a duration of 3hrs during the past 30+ days a one off event ? if it does then IMO thats not right

I 100 % agree that there should be an option made available to all ISP's that would override some changes made by DLM in particular restoring Fast Path for those who play online games ect,

Edited by tommy45 (Tue 07-Oct-14 16:34:01)

Not sure what you mean by "bad programing". The Zen document describes the way the parameters are set for the DLM thresholds. If the system allows these parameters and follows them as intended, to me that is an example of "good programming".

Edited by deleted (Tue 07-Oct-14 17:12:44)

interesting that matches to the 2880 ES/day that someone mentioned here last week.

bear in mind 2 ES per min is very different to 2 CRC per min.

an ES can be dozens of CRC or can be just 1 CRC.

Don't forget that many router stats show ES and SES. I wonder which of those is the ES referred to.

An ES represents a second-long period where one or more CRC errors occurred. I'm pretty sure it is this one that DLM monitors.

An SES, or a severely errored second, has a couple of definitions, and I'm not sure which applies.

Definition 1: A second long period where more than a certain percentage of blocks contains errors (usually set at 30%); this is the way I always thought SES was counted.

Definition 2: One SES is counted when 10 consecutive seconds with a non-zero ES happen.

on a SES both ES and SES tally I believe.

I found this

availability definition is based on a model which uses two states to represent the ability or inability of the network to sustain the service in the available state. The transitions between the states are based on the occurrence of severely errored seconds (SES) in the Ethernet layer.

A severely errored second occurs for a block of frames observed during a one-second interval when the ratio of lost frames to the total frames in the block exceeds a certain pre-defined value. A provisional value of 0.5 was proposed by ITU-T in 2009

These may help too
http://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&sou...

http://exodus.poly.edu/~kurt/manuals/manuals/Other/A...

Edited by deleted (Wed 08-Oct-14 08:58:57)

Here's ZEN's version:
Fibre Optic Broadband - FTTC: What is DLM and how does it work?

In reply to a post by xreyuk123:

I would say the 3-5am statement is wrong. Every DLM intervention I've had has come at 8:01am.

My DLM was resync at 8:56am on the Saturday and again last night at 2:33am. From 79999k to 72000k and now at 67000k

I have just been looking in detail at the introduction of interleaving on my line a few weeks ago; around 15:33 on 20th Sept.
The interleaving was removed after 14 days (around 02:00 on 5th Oct).

This confirms my suspicion that the untimely (eg not in the middle of the night) intervention was not caused by DLM; but forced by a retrain. However, at the time of the retrain DLM observed recent behaviour and introduced interleaving. This interleaving was justified based on the high error rate before the retrain and the low error rate after it.

Leading up to the introduction I had a large number of errored seconds throughout the day, up to 24 per minute. There had been a couple of high bursts earlier in the day, but relatively few errors in the hour leading up to the intervention. I therefore don't think they were a cause of intervention; though quite possibly they had been recorded and would have caused intervention by DLM the following night.

There had been no severe errored seconds at all that day until the minute before the retrain happened; 11 severe errored seconds were recorded during one minute period during which the intervention happened. Presumably some big noise burst caused the severe errored seconds and forced the disconnection/retrain.

~~~
Here is a screen shot of the interactive graph I used for analysis.
https://dl.dropboxusercontent.com/u/4344193/DLMshot.jpg

This uses my own webpage for interactive viewing of BaldEagle's stats; at http://programbits.co.uk/modemGraph/plotstats.html
This has features I find very useful. It can be used by others but I am fully aware there are several rough edges. If anyone feels it could be useful for them but would like to see changes please let me know and I will see what I can do.

Edited by StephenTodd (Wed 08-Oct-14 11:14:10)

In reply to a post by BatBoy:

These may help too
http://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&sou...

http://exodus.poly.edu/~kurt/manuals/manuals/Other/A...

Ta. Added straight into my "useful stuff" folder...

The ITU standard being explored in the second link is a little old. However, for our VDSL2 connections, I suspect that the defects/anomolies associated with PDH are the most relevant, rather than SDH or ATM.

Mine is:

Wed Oct 08 2014 16:22:00 GMT+0100 (GMT Standard Time)
ds_max_rate: 93220
ds_rate: 79999
ds_snr: 9.6
us_rate: 19999
us_max_rate: 34002
us_snr: 15.2
hours_up: 38.684
ds_ES: 30

Edited by adslmax (Wed 08-Oct-14 16:25:07)