Dynamic Line Management. (DLM)

[#1]

I have a query about DLM.
My understanding is that it finds the best speed depending on line length, line condition etc.?
My own experience has been that it tries a speed, if that isn't stable then it reduces the speed. On the other hand, it attempts a higher speed, if that's stable, then tries an even higher speed.
From the Oxford Dictionary -  "adjective
1(Of a process or system) characterized by constant change, activity, or progress:"
So, by definition, should the system be regularly trying to find the best stable speed for a line? Therefore if a line remains static for say, 30+ days, should the DLM system have tried, during that period, a faster speed to determine that faster speed's stability?

[#2]

Are you referring to ADSL DLM or FTTC DLM. They are both similar, depending which way you look at it.
ADSL and FTTC DLM's work in different ways though!

[#3]

Quote from: newagetraveller

My understanding is that it finds the best speed depending on line length, line condition etc.?

Speed is a function of line stability, which is indeed influenced by the line's length and condition, but also by the impact of external electrical noise REIN & SHINE), the quality of internal wiring, filters and modem performance.
There is a good article in the technical library on the operation of FTTC DLM here - http://community.plus.net/library/browsing/fttc-dlm-what-it-is-how-it-works/
As for ADSL unless the line is in training mode, DLM does not attempt resynchs, it just monitors stability and adjusts the target SNRM accordingly.  Lines remain synch'd at whatever speed until something gives rise to a disconnection.  At that point the modem negotiates the highest synch speed which will achieve the target SNRM above the then present noise.
It is that latter aspect which explains why a synch established during night time hours will be lower that that achieved during day light hours on a bright dry sunny day, albeit both at the same SNRM.  At night time there is more electrical noise from MW transmissions to say nothing of the other known culprits.
HTH?

[#4]

Yes DLM can increase your line speed again if it sees it stable, this has been reported to happen by quite a few users on current FTTC products. However, on FTTC it takes a long time, as you say, around 30+ days in most cases before it will raise the line speed. As I understand it, it won't raise the line speed if your error rates are within in a certain range. (Mine are 0.5%, but I haven't had my raised for 14 days).
I believe ADSL DLM is a lot more dynamic, and can change things on the fly, but from what I've seen on this forums, people usually see an increase day by day on ADSL.
I believe the key thing is, that DLM on ADSL can be reset (either by request to BT or by PN themselves depending equipment), which will put it back into the 10 day training period. FTTC DLM can only be reset by an engineer visit, so it's not something you can have done, unless you've had a fault with your line.

[#5]

Thanks for the replies.
Sorry, it's ADSL.
These are the current line stats. TG582n.
DSL Connection
Link Information

Uptime: 5 days, 5:59:27
DSL Type: ITU-T G.992.3
Bandwidth (Up/Down) [kbps/kbps]: 1.044 / 5.259
Data Transferred (Sent/Received) [MB/GB]: 259,06 / 1,99
Output Power (Up/Down) [dBm]: 12,6 / 0,0
Line Attenuation (Up/Down) [dB]: 25,6 / 44,0
SN Margin (Up/Down) [dB]: 3,4 / 7,8
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / IFTN
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 0 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 740 / 0
FEC Errors (Up/Down): 10.573 / 667.005
CRC Errors (Up/Down): 1.725 / 3.126
HEC Errors (Up/Down): 1.961 / 42.699
Stable connection for 5+ days since a powercut. Prior to that it was stable for 30+ days at a slightly higher sync.. So I was only curious as to why, with the line apparently stable the so-called DLM hadn't tried for a faster connection during the two periods?
i used to notice that, quite regularly, the DLM would try for a faster connection which would be stable for a while then change again.
So the "Dynamic" has really now become static!

[#6]

The DLM is always 'static' after the first 10 days, in that it will not deliberately drop the connection. 

[#7]

Hi NAT,
Some observations about your stats...
You are on ADSL2 rather than ADSL2+ which might point to some limit in the ability of your line.
Your synch is about 2Mbps below what might be expected on a 44dB attenuated line.
The 7dB SNRM rather implies that when the line last synch'd up (5 days ago) there was electrical interference present or (at least) it was during the hours of darkness when MW interference is prevalent.  Downloading and running RouterStats will help identify if this is the case.  See "Ratbag's" thread for a good illustration of the impact of REIN from a laptop PSU.
The synch will remain where it is until some event causes a DSL disconnect as I described above.
Is there noise on the line?  Dial 17070 option 2.
Are you connected to the master socket?
If there are extensions, connect to the test socket.
Try a new filter.
See the slow speeds thread at the top of this forum, for hints and tips on improving your speed.
Then I suggest you raise a fault report here http://faults.plus.net

[#8]

Thanks Townman.
My perception is this all started back in May after a multitude of local power cuts.
At the request of PN I connected to the test socket for many days, I think a line reset was carried out and a three day "retrain". As I recall there didn't seem to be any "training" at all. The speed remained static and much less than I was achieving prior to the power cuts.
I'm sure something has happened externally, exchange?, I don't know.
The router is connected to the master socket and the p.c. by ethernet.
I queried about ADSL2/ADSL2+ and was told I was on ADSL2+ which I had been since it was enabled at my exchange. (2years ago?)
I'm convinced, in spite of being told there's nothing wrong, something is different with my connection since mid May (and the numerous power cuts). I did raise a ticket, given a load of gobbldeygook answers, and was told there's nothing can be done, my speeds are within those estimated.
Yes, the last power cut was around 2am 5 days ago.
I know my speed has not fallen off a cliff but I was syncing around 5.7mb/s and more, sometimes over 6mb/s, prior to May, now it's fallen to around 5.2mb/s.
I suppose living where i am I should be thankful for what I get compared to others living in a similar rural location and even further from their exchange.

[#9]

Quote from: Townman

As for ADSL unless the line is in training mode, DLM does not attempt resynchs, it just monitors stability and adjusts the target SNRM accordingly.  Lines remain synch'd at whatever speed until something gives rise to a disconnection.

I don't think that is correct - if the DLM decides error rates are too high, it can cause a resync with a higher target noise margin. At any time, not just in "training mode". It would be pretty pointless if the DLM couldn't force a resync when it decides one a higher target noise margin is needed.
Edit: these documents on the DLM should be fairly clear about the DLM's ability to drop your ADSL sync: http://www.btwholesale.com/pages/downloads/21_Century_Network_Community/DLMWorkshop_291009_material....

Quote from: wbc_dlm_faq_issue1

What happens when a line is re-configured? Re-configuration of a line by DLM will cause a short (typically 20-30 seconds) outage in service when the new line profile is applied.

Quote from: How

In general, DLM only makes one re-configuration per day and this will result in a single retrain of the line – these “auto” retrains are bulk scheduled across all lines throughout the day/night

[#10]

@ejs,
What I meant is the DLM does not resynch on its own to better the synch rate.  Clearly if the line starts encountering errors as you describe, there us no option but to resynch.
NAT is expecting DLM to attempt a resynch to better the synch speed after the 10 day training period - I am not convinced this happens.

[#11]

I expect you don't see it very often because most people don't want to wait an unknown amount of time for the target noise margin to go back down after some one-off event that caused the DLM to raise the target noise margin. I don't think many people will post on these forums when their ADSL speed goes back up automatically.
The DLM is mostly about maintaining line stability. I don't think the DLM behaves differently after the first 10 days - the first 10 days are to set the maximum stable rate (which doesn't set or imply any speed limit, of course), and the fault threshold rate. It's more active during the first 10 days because it doesn't have the historical data to go on.
The MTBE (mean time between errors) needs to be greater than 600 seconds (according to that 2009 DLM workshop stuff I linked to previously), under the standard stability option, for the DLM to classify the line as green and make changes towards higher speeds. According to the stats posted, fortunately the error counters should have been reset due to the power cut, the MTBE for the downstream is:
((5*24*60*60)+(6*60*60))/3126 = 145
That assumes the MTBE is calculated like that (rather than somehow keeping track of error free periods), and that the errors were spread evenly over the 5 days and 6 hours. So, based on various assumptions and somewhat dated documentation, the DLM hasn't tried to increase the speed because the average time between errors is too low, not because the DLM just doesn't do that after the first 10 days.
If you have a perfect line and nothing better to do, you could deliberately do something to cause the DLM to increase your target noise margin, then wait and see if and when the DLM decreases the target noise margin and causes a re-sync or not.

[#12]

It occurred to me that probably the errored seconds count should have been used to calculate the MTBE.
((5*24*60*60)+(6*60*60))/740 = 613
or perhaps subtract the errored seconds from the total time, but it won't make much difference:
((5*24*60*60)+(6*60*60) - 740)/740 = 612
or even, if there were 740 errored seconds, then there were 741 intervals between those errored seconds:
((5*24*60*60)+(6*60*60) - 740)/(740+1) = 611
Although that's slightly higher than the green threshold, the DLM collects the stats for each day, and some days might have had MTBEs lower than 600, and other days higher. There are other factors taken into consideration, noise margin variation, FEC count, and of course the long term line history. Perhaps the DLM has learnt from the past attempts at trying higher speeds, as so is disinclined to try again.
Edit: more MTBE calculation fixing!