Print

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

[ryant704]

Actual 26, Max 30, Attain 28

[ColinS]

Actual 26, Max 30, Attain 28

Thanks. Updated the above as:
Ryant705 after      Actual 26    Max rate 30  Attain rate 28      RPO 86.7%  RCO 92.9%

Suggests that you are now getting pretty much what is achievable for your loop length, within your current profile.  How long is it, do you know?

[ryant704]

800-1000m

31 Attenuation

Just checked on google maps, looking at least 965m + up and down poles.

[burakkucat]

I wonder, given sufficient data from many EUs, whether a sensible graph could be plotted? 

[ColinS]

I wonder, given sufficient data from many EUs, whether a sensible graph could be plotted? 

Sounds like a good idea - all it needs are more EUs and a decent programmer.  Wonder where we might find one of them? 

but with enough EU data, we might be able to identify some empirical rules of thumb ....

[ColinS]

Just checked on google maps, looking at least 965m + up and down poles.

In which case, your results might cause one of our feathered friends to lose even more feathers. 

[Bald_Eagle1]

Just checked on google maps, looking at least 965m + up and down poles.

In which case, your results might cause one of our feathered friends to lose even more feathers. 

Hmmm.

December 2011 - 29430 Sync 34008 Attainable (DS Interleaving depth 467)
Now                    20667 Sync 21116 Attainable (Interleaving OFF)

Line length 1000m to 1200m (max)

 

[ryant704]

I'm going to make you lose a little more feathers... would you be annoyed if I told you I had 200m of Ali as well?

[Bald_Eagle1]

I'm going to make you lose a little more feathers... would you be annoyed if I told you I had 200m of Ali as well?

I'm not quite sure how to phrase this, but the second word is OFF! 

[ryant704]

I'm not quite sure how to phrase this, but the second word is OFF! 

I've lost some speed so it isn't that bad, my original sync was 35Mbps though that dropped to 30Mbps the next day so...

[ColinS]

Also, we are told that DLM 'readjusts' the circuit every evening dependant on behaviours ?? I don't think the 14 day timescale has any other bearing other than that is how the data is presented to us  on WHOOSH .... IE- 7days, 14days and 28days. I'm guessing that 14 days is probably a decent amount of time to gather averages for manual scrutiny, as I say, the DLM acts on its findings every single day.

Following one of Asbokid's posts 'in another place' here http://forums.thinkbroadband.com/fibre/4240841-dlm-fault-recovery.html?page=1#Post4240966
one of BT's patents confirms the 14 day monitoring period, and hence the profile timestamp:

In the present embodiment, each line is processed once every 24 hours to determine how the line should be
categorised, and thus if a new profile should be selected for that line. In order to avoid frequent oscillations between
adjacent profiles, a good and a bad delay counter are used to place a delay on how quickly a line is reprofiled. Thus,
every time a line is categorised as good a good delay counter is incremented (and a poor delay counter is decremented)
and only once the good delay counter has reached a good threshold (which in the present embodiment is set to 13) is a request made to the OSS for the profile to be increased by one step to a more aggressive level, and then the delay counters are reset.

So, in the absence of the events that provoked the reprofiling of the line, it should revert it back one profile level every 14 days ... or at least it would if it was following the mechanics set out in their own patent.
Clearly I'm 'stuck' on my current profile as a result of some subsequent improvement to that patent! 

[ColinS]

An associated BT patent quoted by Asbokid at https://data.epo.org/publication-server/pdf-document?PN=EP2169980%20EP%202169980&iDocId=7293432&iepatch=.pdf has this to say

The DEFAULT GOOD THRESHOLD is set in the present embodiment to 13 (i.e. equivalent to 14 days), the
DEFAULT POOR DELAY is set in the present embodiment to 3 (i.e. equivalent to 3 days) and the DELAY DOUBLER
is set to 0, thus the initial good delay is 13 but each time the line’s profile is transitioned to a less aggressive profile the DELAY DOUBLER is incremented until after 5 such transitions, each time the DELAY is reset it is reset to a value of 448 (i.e. equivalent to approx 14 months). In the present embodiment, if a user’s stability policy or level is changed the delay doubler is reset back to zero; furthermore, the delay doubler and even the delay counter may be manually reset by an operator to cater for exceptional circumstances.

But, what happened to me was it moved back in one transition from 80/20 to 35/20, and it subsequently moved forward again twice, every 3 days, before it stopped.  That was on 14/04/2013 - over 6 weeks ago.

[asbokid]

Credit goes to SevenLayerMuddle.  It was he, way back in 2010, who first noticed that BT had patented its DLM system:

http://forum.kitz.co.uk/index.php/topic,7548.msg158076.html

I'm not 100% persuaded that the discovered patents represents the current state of play, i.e. the current embodiment(!). 

Those patents describe a system that tweaks TSNRM. Yet Openreach's latest DLM algorithm rather than directly tweaking the noise margin, instead relies upon tweaks to interleaving/INP levels and to maximum and minimum data rates, in order to maintain stability and maximum speeds (I'll fetch my coat!)

cheers, a

[waltergmw]

@ asbokid,

Surely we are dealing with a significantly different DLM VDSL algorithm now with additional "features" such as power cut-back and (almost) permanent cap on sub-standard lines.

Kind regards,
Walter

[ColinS]

Credit goes to SevenLayerMuddle.  It was he, way back in 2010, who first noticed that BT had patented its DLM system:

http://forum.kitz.co.uk/index.php/topic,7548.msg158076.html

I'm not 100% persuaded that the discovered patents represents the current state of play, i.e. the current embodiment(!). 

Those patents describe a system that tweaks TSNRM. Yet Openreach's latest DLM algorithm rather than directly tweaking the noise margin, instead relies upon tweaks to interleaving/INP levels and to maximum and minimum data rates, in order to maintain stability and maximum speeds (I'll fetch my coat!)

Well, thank you indeed 7LM.

Yes, Walter I do agree that the stuff quoted above may not fully be the current embodiment.  However, it does have a number of basic characteristics in common with it, which may explain a lot of things that have been debated at length here and elsewhere.
For example, it is probably the source of the debate around the 10-day period. In https://data.epo.org/publication-server/pdf-document?PN=EP2169980%20EP%202169980&iDocId=7293432&iepatch=.pdf at [0063] it says

In the present embodiment, the FTR is initially set at 2Mbs and is then re-set to 80% of the Maximum Stable Rate detected by the network during the first 10 days of operation of the DSL in its rate adaptive mode.

Now, I agree that this patent was for all flavours of DSL, and so that embodiment is probably only applicable to ADSL, but I think these patents can still give us all insights into how they thought it should work, and our collective experiences can shed light on how it appears to work now.  In the absence of BT co-operating to fully publish it, what else can we do?

I am already aware that the patents to not fully describe the current behaviour for VDSL.  I am merely suggesting that, using these as a starting point for discussion, it could assist us in trying to understand how it works now.  Some things have undoubtedly changed, particularly the mechanisms as Asbokid and your good self have pointed out above, but others are still there.  I doubt the basic framework has changed at all, merely the profile contents (i.e. the selected parameters of control).

Has anyone else found a better starting point yet?  I advocate reading them fully and making your own minds up.