Print

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

[jid]

Anyone have any idea why DLM seems to resync the line, but for no reason?

Tonight about an hour ago the line resynced, MDWS emailed me, and its saying reason 1? Anyone any ideas?

jidavies on MDWS

Only slight differences are little lower Interleaving level and lower sync by a couple of 100kbps?

[kitz]

The interleave depth is insignificant, it can slightly change depending upon sync speed and seems to have gone back to what it was yesterday day.   

You appear to have had a resync last night at about 11:15pm after a large noise burst.  Note the burst of CRCs and drop of SNRm.   

The E/S weren't sufficient to trigger a DLM change...  but I wonder....   

I did see something in one of the DLM docs about certain lines which may have been 'unstable' for a while, may be directly monitored by rambo (rather than the usual element managers) for SNRm swings before making any downwards changes. 
I wonder if your line is now (or was perhaps previously) being one of those being SNRm monitored.  I really dont know this is just guess work and supposition.  There is very little info about direct rambo monitoring, other than it can be triggered during an ILQ period, to ensure that the line is actually stable before relaxing any profiles... and that it monitors SNRm swings.   It was only your dip from 6dB to 1dB that made me think of this.  Other than that I have no idea.

[jid]

The interleave depth is insignificant, it can slightly change depending upon sync speed and seems to have gone back to what it was yesterday day.   

You appear to have had a resync last night at about 11:15pm after a large noise burst.  Note the burst of CRCs and drop of SNRm.   

The E/S weren't sufficient to trigger a DLM change...  but I wonder....   

I did see something in one of the DLM docs about certain lines which may have been 'unstable' for a while, may be directly monitored by rambo (rather than the usual element managers) for SNRm swings before making any downwards changes. 
I wonder if your line is now (or was perhaps previously) being one of those being SNRm monitored.  I really dont know this is just guess work and supposition.  There is very little info about direct rambo monitoring, other than it can be triggered during an ILQ period, to ensure that the line is actually stable before relaxing any profiles... and that it monitors SNRm swings.   It was only your dip from 6dB to 1dB that made me think of this.  Other than that I have no idea.

I have noticed though,whenever I get a DLM resync there's a burst of errors, as if that's the dslams way of forcing the resync?

I can think of anything physical, but at 7am had another identical Rdi 1 resync.

Edit: looking back on downstream snr was affected so you may be right Kitz.

[WWWombat]

I'm not sure why you are labelling these two resyncs as DLM resyncs; they don't look like that to me.

DLM normally intervenes by setting/changing only a few parameters - INP and delay, upstream and downstream. If DLM triggered the resync, you'd expect one of these to change. The modems would then re-negotiate the rest of the FEC and interleaving settings.

If INP & delay do not change, but you see small alterations in the other FEC/interleaving settings (such as depth or width of the interleaving block, or the amount of FEC overhead), then that is not a DLM intervention - just the slight adjustments you normally see as a result of any re-sync.

For you, INP downstream stays set to 3, and upstream stays at 0, so neither changes. "delay" is not visible in the MDWS, so I can't comment there; (I tend to find it better to use the graphs for an overview and the full text for detailed analysis)

But, on balance, it doesn't look like DLM intervention at all.

I think kitz gets it right with highlighting the CRC counter. It isn't easy to see the spike now (even when zooming in, the 7am-ish spike stays hidden most of the time), but they look huge - 15,000 CRC's just before midnight and 14,000 CRC's just after 7am.

I have noticed though,whenever I get a DLM resync there's a burst of errors, as if that's the dslams way of forcing the resync?

The other way around - the errors are causing the resync.

I suspect that a burst of noise big enough to create 15,000 CRC errors is easily enough to trigger a loss of sync of some form - highly likely to be a "loss of signal" or "loss of frame".

Judging by my current modem statistics, the "OHF" counter accrues at the rate of 604 every second. This ought to be a count of the frames that are each protected by CRC; each CRC error maps to one faulty OHF. At worst, you can accumulate 604 CRC's per second, or just under 10,000 CRC's in a minute. <- miscalc

If your MDWS graph spikes are correct, you got a burst of noise that lasted over a minute nearly 30 seconds - easily enough for the modem at one or both ends to decide it had lost sync - either because the noise masks the signal, or the noise makes it impossible for the modem to detect the incoming framing bits.

^{Edit: I just checked my graphs from BE's HG612 stats program: it seems to accrue OHF's at a rate of 36,000 per minute; I miscalculated above. Still - 15k of CRC errors is 30 seconds' worth of outage.}

[tbailey2]

For you, INP downstream stays set to 3, and upstream stays at 0, so neither changes. "delay" is not visible in the MDWS, so I can't comment there; (I tend to find it better to use the graphs for an overview and the full text for detailed analysis)

Delay is now available in MDWS graphs, hit Update if you can't see it in the listing 

[NewtronStar]

I have noticed though,whenever I get a DLM resync there's a burst of errors, as if that's the dslams way of forcing the resync?

The burst of errors occurs during the resync it's picked up by both Modem stats and DSLstats and is very common and can only say it's a software fault, I remember seeing a spike of 4000 CRC's and found that the HG612 had done a resync it's a false positive.

[WWWombat]

Delay is now available in MDWS graphs, hit Update if you can't see it in the listing 

Wow... That was a quick update!

[WWWombat]

For you, INP downstream stays set to 3, and upstream stays at 0, so neither changes. "delay" is not visible in the MDWS, so I can't comment there;

Having looked at the (suddenly available) "delay" value, I can confirm that it definitely doesn't appear to be DLM: neither INP nor "delay" have changed.

[jid]

For you, INP downstream stays set to 3, and upstream stays at 0, so neither changes. "delay" is not visible in the MDWS, so I can't comment there;

Having looked at the (suddenly available) "delay" value, I can confirm that it definitely doesn't appear to be DLM: neither INP nor "delay" have changed.

As attached, resync reason code was 1 - which is normally always DLM

[jid]

For you, INP downstream stays set to 3, and upstream stays at 0, so neither changes. "delay" is not visible in the MDWS, so I can't comment there; (I tend to find it better to use the graphs for an overview and the full text for detailed analysis)

Delay is now available in MDWS graphs, hit Update if you can't see it in the listing 

Nice one Tony, that was fast!

[WWWombat]

As attached, resync reason code was 1 - which is normally always DLM

RDI - Remote Defect Indicator: does this really mean DLM intervened?

To my understanding (of telecoms protocols in general), a chipset reports faults and alarm conditions that it detects itself, to the local-end software. It can also receive a valid datastream from the far-end chipset, where some of the bits in the datastream indicate faults and alarms as perceived by the far-end chipset. Some of these far-end indications get passed up to the local software.

As I understand it, an RDI indication is one of those fault indications received within the datastream from the far-end - indicating to us that the far-end is the one having some problems (probably in getting clear reception) - whereas indications such as LOS or LOF are fault indications detected by the local chipset itself, indicating we are having problems receiving the far end. If our local chipset detects something like LOS or LOF, it will report the alarm to our software, but will also start transmitting a "remote defect indicator" back to the far-end, letting them know that we are having problems with reception.

I'm not absolutely convinced that RDI applies to VDSL2 - googling seems to show it belongs to earlier generations of telecoms equipment - PDH and the like, with "all 1's" alarms. That takes me back to the eighties...

In this case, the problem could be that the noise is more severe on the upstream side; your modem counts a lot of downstream errors, but it is the DSLAM that gives up first and requests a resync.

[jid]

As attached, resync reason code was 1 - which is normally always DLM

RDI - Remote Defect Indicator: does this really mean DLM intervened?

To my understanding (of telecoms protocols in general), a chipset reports faults and alarm conditions that it detects itself, to the local-end software. It can also receive a valid datastream from the far-end chipset, where some of the bits in the datastream indicate faults and alarms as perceived by the far-end chipset. Some of these far-end indications get passed up to the local software.

As I understand it, an RDI indication is one of those fault indications received within the datastream from the far-end - indicating to us that the far-end is the one having some problems (probably in getting clear reception) - whereas indications such as LOS or LOF are fault indications detected by the local chipset itself, indicating we are having problems receiving the far end. If our local chipset detects something like LOS or LOF, it will report the alarm to our software, but will also start transmitting a "remote defect indicator" back to the far-end, letting them know that we are having problems with reception.

I'm not absolutely convinced that RDI applies to VDSL2 - googling seems to show it belongs to earlier generations of telecoms equipment - PDH and the like, with "all 1's" alarms. That takes me back to the eighties...

In this case, the problem could be that the noise is more severe on the upstream side; your modem counts a lot of downstream errors, but it is the DSLAM that gives up first and requests a resync.

Interesting reading, especially with regard to upstream. I used to be interleaved upstream but now DLM hasn't seen the need to after a HR fault was resolved a few weeks ago.

A pair swap solved all the problems I was having, its not something I'm concerned about, I just thought it was strange to see the RDI resync reason code.

It all seems OK now, error rates are perfectly acceptable imo on the line and not bothered at all about interleaving being applied Downstream.

Sent from my Nexus 6 using Tapatalk

[NewtronStar]

Some of these far-end indications get passed up to the local software.

Interesting the far-end (gateway) as you call it may be a way to end the old PPPOE connection on the modem and assign a new one if the gateway is having issue.