Print

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

[les-70]

  SHINE is the trouble maker on my line.  I wonder over some arcing switches in the area round here.

   From the various examples in mydslstats I think we can be fairly confident that CRC are not directly counted. I guess that a CRC spike is bad enough to worry about, the DLM thinks it will be associated with a resync.

[kitz]

D'oh.    Ive always said that the DLM doesnt use CRCs.  I just thought this would prove it once and for all which is why I said IF.
I am fully not expecting to be DLM'd.  I wasnt DLM'd today for yesterdays, nor am I expecting to be tomorrow for todays.
This has been discussed many times and Ive always stuck to Errored Seconds.  Ive debated this several times and this is my thoughts on the subject.

~ Detection of Errors

The DLSAM's Data Collector will record the amount of errors seen on your line. These will be the same errors as displayed by your modem/router.  It is not known exactly which errors it uses, documentation states 'Code Violations' and it is assumed to most likely be Errored Seconds.

It is unlikely to use FECs as these just prove that interleaving is working as it should plus FEC is not a code violation. A single CRC error or burst of CRCs will usually triggers an errored second event. It is also known that xDSL Status Test Summary only records Errored Seconds and HEC errors.

Note: In all the documentation I've seen there is only one parameter for 'Errors' that is recorded by the Element Manager. However, there are instances whereby if a line is performing particularly poorly, then RAMBO will undertake additional line monitoring direct with the DLSAM.  In such cases it monitors additional parameters such as SNR Margin which are not normally monitored at all for most lines.  For more information see: DLM System - Additional Line Monitoring.

What is SHINE? forgive my dumbness

Slaps Chrys with a wet fish,  I included a link in my post to explain what SHINE was.

What I dont know is the exact MTBE red thresholds for each of the stability metrics.  Ive come across several metrics that they could be using.  ATM I believe 30 on speed is the most recent that is documented anywhere.   I have my suspicions though that there may be another newer algorithm out there for speed.  When Ive sorted out a few R/L and far more important things then Im going to look further into that, because something is still nagging me re 'speed' and stable which doesnt quite sit right atm.

The other thing I dont know is the exact time metric start and finish.
 
Ive said for months that MTBE is normalised to uptime.  Documentation says 24hrs..  but I dont know when the 24hrs starts and when it ends, because we dont know at what time the Element Manager passes the data over to the DLM Management Device

[Chrysalis]

thanks guys, yeah SHINE I expect would be nigh impossible to find, but the good news is DLM shouldnt act on it.

[Chrysalis]

looks like I had 10 SHINE events today

rather have SHINE than either REIN or PEIN, since SHINE will come and go in a flash the chances of it affecting anything you doing is small.

[Black Sheep]

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).

[kitz]

PEIN = Prolonged

Ive never really looked at PEIN as its not something you seem to hear as much about because most of us have seen samples of REIN and SHINE but not PEIN.   

I just did a google on PEIN, and found this which I found interesting
http://www.joepeesoft.com/Public/DSL_Corner/Docs_ETSI_TM6/071t29_Noise_PEIN.pdf

OMG I have a PEIN in my U0  !!!!1!!!111one*

PEIN isnt something we tend to see that often, but its interesting that its now recognised as a type of interference in its own right.  I should update the REIN page to include it..






[PS to BS
 I am jk about the PEIN - Im not concerned about it and know theres nothing I can do, sit back and relax ]

[Black Sheep]

Ha ha ............... thank the mighty lord for that, Kitz. 

Have a look at this regarding your other musings.

[kitz]

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).

Thank you muchly Mr Black Sheep.      You wont believe the documents & white papers Ive trawled through and read over the past few months whilst trying to put together the DLM pages.   

Most of the DLM stuff says 'code violations'.    A code violation discounts FECs but could include CRCs, ES and SES.
 
However I saw absolutely no reason why they would count individual CRCs because a CRC would trigger an ErrSec anyhow and IMHO theres no point recording all the individual errors during that noise burst.   Its way more sensible to measure that a noise burst has occurred.  Its just that Ive not seen BT put Err/Secs in writing.  The nearest I have seen is ErrSecs and SES.

[kitz]

Ha ha ............... thank the mighty lord for that, Kitz. 

Have a look at this regarding your other musings.

WOW!   I love you Mr Black Sheep.   Thank you so very much.    I had a feeling in my bones that the other figures weren't right and that they'd done an update,  I'd seen mention of an update, but no hard figures.   There the ones I was looking for.   Do you happen to know when they came into effect.   I think it may have been fairly recent within the past few months. .

[Black Sheep]

The doc is dated late April this year .......... glad you're a happy bunny. 

[kitz]

Thanks for that, Ive seen so many algorithms, but none of them seemed to fit what we've been seeing recently.

These were the original figures

Code: [Select]

Service Option MTBR red threshold MTBR green threshold MTBE red threshold MTBE green threshold
1 8,640 16,800 60 600
2 16,800 33,600 600 6,000
3 33,600 67,200 6,000 60,000
Then last year they halved them, but I saw something that implied they may be reviewing and reducing further.    It seems to be all change with Rambo atm, and its looking like he may be retired in favour of a new system.  Those of us on the new MSE bRAS (fttc goes first) are seeing all sorts of changes.  Since the change, my broadband connection no longer goes through my own exchange - instead the fibre goes straight to the MSE bRAS location in another town, and hops on the core quicker.. which is why some of us have seen the odd ms shaved off our latency.

glad you're a happy bunny

yep thanks.   Im a sad git who is easily pleased.    As you know I go in hopical tomorrow.. armed with all my juicy reading material I shelled out for for last week.   Some really  good stuff in there.   Ive only skimmed so far, but the contributions from people in there from Adastral Park inc appx 30 from BTw and BT Exact is huge.  Some of it is dated, but all the FFTC stuff is there including FeXT projections, from the guy who designed the fttc platform. So thats my reading sorted for a good  while.

[Black Sheep]

Ha ha ...... you is a nutter, lady. I can picture the faces of the nurses when they see all your DLM papers ! Hope all goes well for you. 

[Chrysalis]

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).

you mean my comments.

I am the one mentioning ES.  I got no idea why kitz confused things mentioning CRC.

[Chrysalis]

Ha ha ............... thank the mighty lord for that, Kitz. 

Have a look at this regarding your other musings.

indeed this suggests the 2880 is outdated info and also interesting is a custom field, might mention that to plusnet next time they say they have no control.

so do I have this right?

on standard 17280 ES day before action?
on stable 288 ES day before action?
on super stable just 24 per ES per day?

these seem odd.  The older figures seem to have closer correlation with user's data.

With these new figures newt should be back on fast path.

[kitz]

indeed this suggests the 2880 is outdated info and also interesting is a custom field, might mention that to plusnet next time they say they have no control.

Ive mentioned the custom field several times in the past going back months.   Thats not for Plusnet..  thats for Openreach. 
Sheesh I was beginning to think no-one was listening to my earlier posts on DLM..  and now I know they werent, because I keep repeating myself.     
 
Remember how I said just the other day how Openreach becomes a customer of BT Wholesale, when we were talking about plans to scrap the Wholesale Division and I linked to the pretty picture

* The current situation is that BTw controls all the profiles via NCAS & the OSS.  The SP hooks into NCAS and can make configuration requests.
However with FTTC, Openreach becomes a customer of BTw so only BToR has access to the OSS to perform any changes and the ISP has no direct access.  Same as any third party/white label supplier has no direct access to DLM and has to go via whomever they purchase from.
 
Further evidence that Openreach is a customer of BTw is also shown in the fact that they don't use the normal stability levels and instead use the custom thresholds which is why we see E/Secs rather than SNR parameters and all the confusion between Standard /Stable/Speed.  

These additional layers only serve to complicate things for the ISP and EU.  So yes I believe merging the two would be beneficial to the consumer.


But the diagram shows what Im trying to say, whereby when BToR becomes the customer of BTw, then it breaks the chain where the dotted orange line is for any config changes.