Print

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

[WWWombat]

no for DLM to remove interleaving the ES has to be below 10% of the normal limit, so e.g. 280.

Also if they on the standard profile its just 140 allowed.

Maybe I wasn't entirely clear.

The ES count of (just below 2800) accumulated over 70 days - so an average of 40 per day. So it seems highly likely that the majority of days would have been green, and highly unlikely (and, if on the speed profile, absolutely certain) there were any red days. In the middle, we could be looking at 10-20 orange days as a worst case - though there would be 50 green days to match.

What event is it that adds extra time onto (doubles?) the recovery mechanism (I've forgotten what it is called ... ILQ?) - an orange day, or a red day?

Following on from Wombat's posting . . .

So you believe that the rate of change of the FEC count has a significance to the DLM process. That is something I have never previously considered but after a quick think, I would agree that it does seem to be feasible.

In the terms of, say, DSLstats it is the delta FEC count per minute.

Hmmm. I had really been thinking that they convert FECS to an MTBE figure, in the same way they convert ES - and test that against some unknown thresholds.

However, when I look at line statistics for people, I tend to look at the ratio of RScorr to RSuncorr, and the ratio of RSuncorr to CRC. That gives you a feel for how effective the FEC process is being, and how many RS errors would convert to CRC errors if all error correction was taken away ... and it has always left me with a sneaky feeling that DLM *ought* to do something similar. Exactly how ... that's the quandary.

[burakkucat]

Agreed. 

[way off topic]
And, if I may be so bold, I would like to regard you as a maestro of extracting sense from the vagaries of circuit statistics. Coupled with Kitz' scouring of publications and analysis of the possible (if not probable) behaviour of the various DLM processes, I believe that (when the time is ripe) the pair of you will be in a position to give a good description of the innermost workings of the various processes. 

(Hmm . . . b*cat has started to waffle.    Time to find my food bowl.)
[/way off topic]

[kitz]

FWIW. I'm using Current Firmware Version: 1.00(AAKL.6)b1

I did have a brief stint with 6b2 (iirc) which was when they changed the max telnet sessions and I had a couple of lock ups because I use both dslstats and hg612 modem stats.  I rolled back to 6b1 and since then Ive been continually up without any problems.

Current up time is 78days (see attached)

[kitz]

Re FEC's,  I think thats been well discussed in other threads.   Ive scoured and scoured any DLM docs I can get my hands on and the only parameters recorded by the element managers are MTBE and MTBR.  Ive further had it clarified via various sources that MTBE is only Err Secs and SES.  FEC is definitely not included.

[more off topic stuff]

However there is a state on the ILQ whereby some lines may require additional monitoring.   Facts about this are hazy atm, because Ive had to draw a halt to my research as Im now spending much of my days elsewhere and not getting home until very late at night.  But from what I can recall it seemed to imply that a previous very unstable line may not only have to go through the 'doubler' stage of green, but also may directly bypass normal monitoring at the element managers and be monitored directly via RAMBO, which also has the ability to record changes in SNRm to make sure it wasnt swinging too much.  I dont know how much of a swing it allows, but I suppose it could be possible to have a line that gets random burst type errors which could cause SNRm spikes sufficient to stop DLM making a reduction. These same bursts could also be causing the recording of a lot of FECs.