Print

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

[kitz]

Openreach probably doesnt care, if it does not make any difference to the DLM or BT side of things.

Wish I could recall where I saw that ISP's may use it during troubleshooting     

[kitz]

Found something about it.

Is this new as its the first reference I've seen in SIN 498 about this.

Cant find a changelog but earliest ref I can see to SIN498v7p1 appears to be Feb 2016

SIN 498

Note:  “Dying  gasp”  is  not  a  mandatory  requirement  but  CP’s  are  encouraged  to
implement  this  in  their modems as  it  will  enable  the  Openreach  Test  &  Diagnostic
systems  to  differentiate  between  a  modem  being  turned  off  by  the  end  user
(loss  of power) or a loss of signal (loss of connectivity) caused by a potential network or home
wiring  issue.

This  will  support  CPs  in  their  diagnostic  approach  to  ensure  that  their
End  Users  have  checked the relevant  setup  prior  to  submitting  a  fault  to  Openreach,
thus avoiding a potentially chargeable engineering visit.

[digitalnemesis]

That's the one. Spot on!

Cheers love 

[PhilipD]

Hi

The 15 minute so waiting 30 minute before reconnecting doesn't matter surely for a few re-syncs in a row.  I've never waited any time before connecting and reconnecting and have made several connections/disconnections with minutes and it's made no difference.

Surely the DLM logic is clever enough to know what interventions are required based on error rates only?  If a plug is pulled so all VDSL signal is completely lost (or power turned off), surely it would know by a complete absence of signal that no matter what intervention it could apply in the way of interleaving, G.INP, banded profiles etc it isn't going to allow the VDSL signal to jump through the air and find it's way back into the RJ11 plug laying by the socket disconnected?  They must have something in place to know the lead has been pulled or power turned off and for that to be ignored by the DLM?

Is this an urban type myth thing, the 15 minute window, or do we know it really exists?  It sounds like something that would be a stupid thing if it was true.

Regards

Phil

[William Grimsley]

Hi Phil,

If you do 20 connections or more within 24 hours, DLM will then take action.

[kitz]

@PhilipD

I can guarantee that BT's use of 15 min bins to detect unforced retrains for DLM is absolutely true.

Theres more info about how DLM decides what is and what isnt an unforced retrain here, and how it uses the 15 min bins here:
DLM process - Detection of sync events  &
DLM process - Check for Unforced Retrains

DLM uses the MTBR calculation to decide whether to take action on what it decides as too many unforced retrains.  MTBR = uptime/no of unforced retrains.

You are correct that it will ignore 'x' amounts of retrains per day.   'x' depends upon your days uptime and the stability level set by your ISP.

[Chrysalis]

yeah I got no doubt about the 15 min bin's.

Nice find on the dying gasp thing, I will continue to always pull power, and leave for 31mins+ process.

[MrBelter]

I have always swapped modems and modem/routers as and when i have liked even when i was on normal ADSL, i have never bothered waiting any time and i have never had any problems with the DLM playing up, i just don't think i'm doing it enough times in one to day to matter.

[kitz]

>> Nice find on the dying gasp thing,

Im sure Ive read SIN 498 numerous times and not spotted that paragraph before. 
I was trying to find a change-log to see the data of change and what they changed, but there didn't appear to be one.
The only thing I could find from a quick scan is that the first reference to SIN498v7p1 was Feb this year.

A search on that paragraph only pulls up SIN498v7p1, but that in itself isn't conclusive evidence that is when they added it. 

 

[ejs]

The change log for BT SIN 498 is in the SIN document itself, before the long annexes with the test procedures. It says it was added in v5 dated June 2013, which is the oldest version I have a copy of. The paragraph about dying gasp is in the Ethernet OAM section, the optional requirement to support dying gasp is R.OAM.4, perhaps it has seen little attention because most people concentrate on the VDSL2 requirements section.

[kitz]

Thanks ejs.

[digitalnemesis]

xdslcmd connection --down

works on HG612 after sh

[roseway]

On the HG612 the commands begin with 'xdslcmd', so 'xdslcmd connection --down' should work. Sorry if you know this perfectly well, but you do have to enter 'sh' at the ATP> prompt to get to the Busybox shell where you enter the xdslcmd commands.

[digitalnemesis]

We forgot to mention this when you have done a 30 minute power off you must leave the modem on for another 30 minutes before the next power off

This should give you a retrain reason 0 each time if you don't you will see a retain reason 1 which is not good.

What's the difference between retrain reason 0 and 1?

[digitalnemesis]

On the HG612 the commands begin with 'xdslcmd', so 'xdslcmd connection --down' should work. Sorry if you know this perfectly well, but you do have to enter 'sh' at the ATP> prompt to get to the Busybox shell where you enter the xdslcmd commands.

Thanks, I forgot to do that.