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)