Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 ... 6 7 [8] 9 10 ... 20

Author Topic: Observations of the FTTC DLM ES threshold  (Read 103411 times)

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Observations of the FTTC DLM ES threshold
« Reply #105 on: November 18, 2014, 06:29:11 PM »

And perhaps GCHQ will take Openreach, Operate and all the infrastructure away from Beattie, for the good of the Nation. :-X
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

strontium90

  • Member
  • **
  • Posts: 88
Re: Observations of the FTTC DLM ES threshold
« Reply #106 on: November 22, 2014, 07:11:49 AM »

Ok..I've been following this thread for a while now and I grasp that DLM applies interleave when a line exceeds ES thresholds.

However, I can see no explanation of what criteria DLM uses, or a timescale of when DLM deems the line ok and puts you back to fastpath...My stats are on MDSW (username Strontium) and my line has held sync for 38 days with no DLM intervention..there is nothing glaringly bad about my stats and apologise for my ignorance if I've missed something..it's a long line btw but even so...
Logged

les-70

  • Kitizen
  • ****
  • Posts: 1254
Re: Observations of the FTTC DLM ES threshold
« Reply #107 on: November 22, 2014, 08:09:53 AM »

 In short I don't think it is clear either.  It is also not clear in all cases which DLM posters refer to FTTC or adsl2.

 If you read through the thread carefully there are suggestion that the criteria may be less than 6 ES/hour coupled with knowledge of line history. In contrast the observation is that there are quite a few like you with about or less than 1ES/hour who seem stuck on interleaved.  However a few have gone fast path with rather more ES/hour than you.

 It has been suggested that when interleaved FEC may also be monitored but no criteria is clear.    I did wonder about looking at average FEC rates of the interleaved lines but FEC are so spiky that you can't guess an average from mydslwebstats.
Logged

strontium90

  • Member
  • **
  • Posts: 88
Re: Observations of the FTTC DLM ES threshold
« Reply #108 on: November 22, 2014, 08:19:10 AM »

Cheers Les-70...perhaps I should try powering down the modem And rebooting after 30 mins?
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Observations of the FTTC DLM ES threshold
« Reply #109 on: November 22, 2014, 02:14:31 PM »

Thats because the DLM system is the same regardless if its FTTC or adsl.   What is different is the configuration parameters. 

I know for a fact that the BTw system was a few years ago supposedly originally aligned to match the BToR system to be able to map the  Standard -> Speed, Normal -> Stable etc

The last policy change for FTTC MTBE may have occurred late 2012.  Thats the last date I can find that specifically mentions FTTC policy.   I cant find any more info than this, but as I keep saying,  it is something I intend to follow up when I get chance.

However, I'd seen something that implied MTBE may be changing this year...  and as confirmed by BS in this thread, it would appear that indeed the adsl2+ system at least has reduced their parameters for Standard MTBE...  but whether or not  BToR system for Speed has also followed is not yet clear.

As regards to why some people get interleaving switched back on the next day and others can take months, there is a reason for that too.. its what used to be called Blip Logic... but now its more complicated and Ive seen something to infer that it could take some lines anything up to over a year to get back :(   (Cant recall figure now but something like 15mths - dont have the documentation to hand to check- so don't quote me on that)

I doubt that the DLM monitors FECs.  All documentation says Code Violations.. of which an FEC isnt!  However, there are instances where the Management box can directly monitor a line (bypassing the Element Managers)  that is classified as performing very poor..  and in such cases do monitor other parameters such as SNRm.
« Last Edit: November 30, 2014, 02:51:46 PM by kitz »
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

les-70

  • Kitizen
  • ****
  • Posts: 1254
Re: Observations of the FTTC DLM ES threshold
« Reply #110 on: November 22, 2014, 05:50:12 PM »

Thats because the DLM system is the same regardless if its FTTC or adsl.   What is different is the configuration parameters. 

  Thanks for that I was not aware that it was the same, even if parameter changes can make the outcomes rather different.   I will however, for the moment, trust what I see on mydslwebstats more than theory as getting reliable info seems hard to do.
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: Observations of the FTTC DLM ES threshold
« Reply #111 on: November 22, 2014, 11:33:21 PM »


As regards to why some people get interleaving switched back on the next day and others can take months, there is a reason for that too.. its what used to be called Blip Logic... but now its more complicated and Ive seen something to infer that it could take some lines anything up to over a year to get back :(   (Cant recall figure now but something like 15mths - dont have the documentation to hand to check- so don't quote me on that)


Cheers Kitz you have just ruined my day   ;D
There was me thinking if I cap my downstream to say 25000 kbps and wait for 14days i'll get a chance to experience fastpath and no way I'm gonna wait 15 months to see if the experiment worked or not   :(
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Observations of the FTTC DLM ES threshold
« Reply #112 on: November 22, 2014, 11:47:51 PM »

Blip logic is now called doubler something, so each step takes longer to recover from.   I promise I will get around to putting all the info up as soon as I can.    I think I fell down a rabbit hole when looking at DLM.  :silly: :crazy: I never realised the 21CN/FTTC one was such a large topic.   I covered it many years ago when maxdsl first came in.   Then never bothered with it for years when on BE* - didnt need to.   Its so bleeping complicated now.  Before I put something up on the main site though, I want to be pretty damn certain of the facts and make sure I fully understand it all, before trying to explain it to others.    The pieces are slowly coming together, most of it is straightish in my head aside from the missing MTBE for FTTC Speed profile. 

--
Edit MTBE typo
« Last Edit: November 30, 2014, 02:50:48 PM by kitz »
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: Observations of the FTTC DLM ES threshold
« Reply #113 on: November 23, 2014, 12:33:37 AM »

I never realised the 21CN/FTTC one was such a large topic.   I covered it many years ago when maxdsl first came in.   Then never bothered with it for years when on BE* - didnt need to.   Its so bleeping complicated now. 

I know Kitz it's friken hard to see the DLM collation from interleaved line to non-interleaved line could it be down to ES/SES CRC SNRM or even attenuation and others there must be constant and you will find it I am sure of it  ;)
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Observations of the FTTC DLM ES threshold
« Reply #114 on: November 23, 2014, 01:37:25 AM »

Everything Ive seen says Code Violations, which totally rules out FECs. Code Violations could be either CRCs/ES/SES.  Im pretty certain it doesnt use CRCs, it would be far to easy to exceed the MTBE, plus Ive exceeded that a few times myself over the past week or so and touch wood the DLM left me alone.

The Element Manager only has one parameter for errors which it uploads to the Management Device for DLM.   As far as DLM goes all the Management Device (RAMBo) seems to need from the Element Manager is uptime, Errors, retrains & sync speed.
There is another file that the Element Manager produces, but thats just a very simple binary file, which RAMBo uses to identify wide area events and unforced retrains.
Oh and the OSS keeps a record of line data for a period of time, but I think thats more to do with say when the ISP says runs a WHOOSH and for fault finding, and nothing to do with DLM/RAMBo.   

The only thing up until last week that said anything specific was a mention of ErrSecs and SES..  then Zen came up with the FECs.
However last week BS checked and found this:

From a DLM doc ...... backing up Kitz comments.

Mean Time Between Errors (MTBE) = Uptime / Errored Second Count. MTBE measures errored seconds only (Not HEC, CRC or FEC).

There is one instance though when DLM will perform additional monitoring and thats when a line goes Scarlet (Very Poor).  At this point RAMBo goes into overdrive and kicks the Element Manager into touch, bypassing it completely.   It then undertakes intensive monitoring of the line direct with the DSLAM.  During additional line monitoring, RAMBo looks at other parameters such as SNRm to see if it can figure out whats going on.   During this intensive care stage, a line's DLM can be immediately changed, it doesnt have to wait for the normal 24hr monitoring reports.  Im beginning to wonder if this is where FECs may have crept in :-\
RAMBo does not directly monitor every single line, the vast majority of lines data gets collected by the DSLAMs Data Collectors and over to the Element Managers... then once a day to RAMBo.

Im still open to the possibility of FECs being used, but atm Ive seen nothing in writing which would back this up.   Its the blip logic/doubler process which is used to decide when parameters are removed.  It may also depend on which parameter caused the DLM to kick in because these are permanently recorded as RED(retrains) or CRIMSON(errors)

---
PS Im saying RAMBo only because most people are familiar with that name, but strictly speaking it should now be called Management Device.   The DLM has now become the major function and the RAP process does comparatively very little since 21CN/FTTC - and absolutely nothing for the GEA Fibre lines.
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: Observations of the FTTC DLM ES threshold
« Reply #115 on: November 23, 2014, 02:24:55 AM »


As regards to why some people get interleaving switched back on the next day and others can take months, there is a reason for that too.. its what used to be called Blip Logic... but now its more complicated and Ive seen something to infer that it could take some lines anything up to over a year to get back :(   (Cant recall figure now but something like 15mths - dont have the documentation to hand to check- so don't quote me on that)


Cheers Kitz you have just ruined my day   ;D
There was me thinking if I cap my downstream to say 25000 kbps and wait for 14days i'll get a chance to experience fastpath and no way I'm gonna wait 15 months to see if the experiment worked or not   :(

Capping your connection will reduce your ES, so try it it may get you back on fastpath.

The longer DLM recovery is more so for lines that have been bouncing a lot, yours hasnt been bouncing but just stuck on interleaving for a long time.
Logged

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: Observations of the FTTC DLM ES threshold
« Reply #116 on: November 23, 2014, 05:30:11 PM »


The only thing up until last week that said anything specific was a mention of ErrSecs and SES..  then Zen came up with the FECs.
However last week BS checked and found this:

From a DLM doc ...... backing up Kitz comments.

Mean Time Between Errors (MTBE) = Uptime / Errored Second Count. MTBE measures errored seconds only (Not HEC, CRC or FEC).


Im still open to the possibility of FECs being used, but atm Ive seen nothing in writing which would back this up.   Its the blip logic/doubler process which is used to decide when parameters are removed.  It may also depend on which parameter caused the DLM to kick in because these are permanently recorded as RED(retrains) or CRIMSON(errors)


FWIW, Asbokid provided the following resync reasons quite a long time ago.
I think the information was geared mainly to VDSL2 connections, but I'm not 100% sure:-

Code: [Select]
Los Detector                   0
Rdi Detector                   1
Negative Margin                2
Too Many Us FEC                3
CReverb1 Misdetection          4
Teq Dsp                        5
Ansi Tone Power Change         6
Ifft Size Change               7
Rack Change                    8
Vendor Id Sync                 9
Target Margin Sync            10
Tone Ordering Exception       11
Command Handler               12
Dsl Start Physical LayerCmd   13
Unknown                       14
G992 Failure                  15
Ses                           16
Co Min Margin                 17


I don't know what some of the reasons mean, but from monitoring my own & quite a few other users' VDSL2 connections, these are the only reasons I have seen:-

Reason 0 - Modem reboot or modem power off/on
Reason 1 - Unconfirmed, but seems to be a DLM initiated resync (often in the early hours but has also occasionally been seen) at other times
Reason 2 - User initiated resync (not a full modem reboot)
Reason 3 - Very, very rare - unconfirmed as to whether it was actually FEC related (DS or US)
Reason 4 - Also very, very rare, but again, unconfirmed as to what actually caused it.

So, I suppose that if a connection reyncs at a lower speed in order to apply interleaving (or at a higher depth for already interleaved connections) & thus reduce various error counts (FEC included), High FEC counts COULD indirectly account for a resync that maybe IS taken into account.

Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: Observations of the FTTC DLM ES threshold
« Reply #117 on: November 23, 2014, 06:16:43 PM »


As regards to why some people get interleaving switched back on the next day and others can take months, there is a reason for that too.. its what used to be called Blip Logic... but now its more complicated and Ive seen something to infer that it could take some lines anything up to over a year to get back :(   (Cant recall figure now but something like 15mths - dont have the documentation to hand to check- so don't quote me on that)


Cheers Kitz you have just ruined my day   ;D
There was me thinking if I cap my downstream to say 25000 kbps and wait for 14days i'll get a chance to experience fastpath and no way I'm gonna wait 15 months to see if the experiment worked or not   :(

Capping your connection will reduce your ES, so try it it may get you back on fastpath.

The longer DLM recovery is more so for lines that have been bouncing a lot, yours hasnt been bouncing but just stuck on interleaving for a long time.

You know Chry I may setup the cap this evening, just would like the full command line instructions be it using Telnet and if the HG612 is powered off does the command still survive ? can you use DSlstats custom commands for this ?

Never mind have capped my DS sync from 30000 kbps to 25000 kbps and a wee bit from the US so lets see what happens  :-\

As my DS has never been moved onto non-interleave how long should I wait ?
place your bids please the winner gets my old Dlink 2640B modem  :D
« Last Edit: November 23, 2014, 07:58:10 PM by NewtronStar »
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: Observations of the FTTC DLM ES threshold
« Reply #118 on: November 23, 2014, 08:53:09 PM »


Reason 0 - Modem reboot or modem power off/on
Reason 1 - Unconfirmed, but seems to be a DLM initiated resync (often in the early hours but has also occasionally been seen) at other times
Reason 2 - User initiated resync (not a full modem reboot)
Reason 3 - Very, very rare - unconfirmed as to whether it was actually FEC related (DS or US)
Reason 4 - Also very, very rare, but again, unconfirmed as to what actually caused it.


Yes BE1 you would like Reason 0 thats the best one, though it takes the HG612 to be powered off for just over 30 minutes to get it.
Logged

Ixel

  • Kitizen
  • ****
  • Posts: 1282
Re: Observations of the FTTC DLM ES threshold
« Reply #119 on: November 23, 2014, 10:35:04 PM »

Yeah, I have a feeling FEC's may not be used as it may not be an accurate measurement - for example it's not the number of FEC seconds? One way to test this might be if I set my ASUS device to go on heavy interleaving for a month (assuming I'm not on a long delay of some kind with increasing the profile) and that way I should produce a large amount of FEC's (this device does that on interleaving, but connection itself is stable however) but a minimal or non-existent amount of ES. I will try it if people want me to.
Logged
Pages: 1 ... 6 7 [8] 9 10 ... 20