Some modems have a Dying Gasp communication function with the DSLAM if it is powered off, and so powering it off is preferable to unplugging the DSL line from the modem, as that may cause errors that are recorded by the DSLAM and held against you.
Just got round to testing this with the HG612 and the ECI vg3503j (Revision /r) VDSL2 modems from Openreach.
Here's the kernel logging (to UART) from the HG612 up to the point that its power plug is pulled:
Line 0: xDSL G.994 training
Line 0: VDSL G.993 started
Line 0: VDSL2 link up, Path 0, us=20000, ds=79987
2000-1-1 0:1:17 Notice 104500 DSL activate succeed
# =====>Now,begin dying...
D%G
And there ^^^^ is the
Dying Gasp message (D%G) being sent by the
HG612 to the DSLAM as its 12v power lead is pulled out.
Over at the DSLAM.. We can see this
Loss-of-Power state recorded in the statistical performance log for that subscriber port.
MA5616(config-if-vdsl-0/3)#display statistics performance 0 line-showtime cpe ever-before
------------------------------------------------------------------------------
Count of forward error correction seconds : 0
Count of errored seconds : 0
Count of severely errored seconds : 0
Count of loss of signal seconds : 0
Count of unavailable seconds : 41
Count of leftr defects seconds : 0
Count of the number of error-free bits passed(64kBit) : 0
Minimum error-free throughput : 0
Count of loss of frame seconds : 0
Count of loss of link seconds : 0
Count of loss of power seconds : 22 (and rising)
..
------------------------------------------------------------------------------
So the
Huawei HG612 and the
Huawei MA56xx DSLAM both communicate and record the
Dying Gasp and loss of service due to
Loss of Power. (22 seconds lost at this point).
The seconds from
Loss of Power can be subtracted from
UnAvailable Seconds (UAS), a counter which also includes the time taken to sync up.
Now we can try the next stage of the
Dying Gasp Test (defined in TR-115 Iss.2 Amnd.1 May 2013) [1]. That is to disconnect the live loop between the DSLAM and the HG612. Simply by pulling the DSL cable from the modem.
Resetting the DSLAM's statistical counters first.
MA5616(config-if-vdsl-0/3)#chipset reset 0
Note: Please don't operating on port while chipset resetting, are you sure to continue? (y/n)[n]:y
We can see, below, that pulling the DSL cable causes no
Dying Gasp message to be sent.
Consequently, the
Loss of Power counter at the DSLAM remains unchanged. Only the
UnAvailable Seconds counter is incremented. Perhaps, surprisingly, there is no change to the Loss of Link counter.
MA5616(config-if-vdsl-0/3)#display statistics performance 0 line-showtime cpe ever-before
------------------------------------------------------------------------------
Count of forward error correction seconds : 0
Count of errored seconds : 0
Count of severely errored seconds : 0
Count of loss of signal seconds : 0
Count of unavailable seconds : 31 (and rising)
Count of leftr defects seconds : 0
Count of the number of error-free bits passed(64kBit) : 0
Minimum error-free throughput : 0
Count of loss of frame seconds : 0
Count of loss of link seconds : 0
Count of loss of power seconds : 0
Now another test (not in the prescribed TR-115 Dying Gasp Test). We will cause a loss of sync by introducing a high level of line noise to see how the DSLAM records those seconds of lost service.
Here's what the HG612 kernel reports to UART when that line noise is injected. It immediately re-syncs (albeit at massively reduced speeds because of the noise).
Line 0: VDSL2 link down
2000-1-1 0:25:32 Notice 104500 DSL deactivate
Line 0: xDSL G.994 training
Line 0: VDSL G.993 started
Line 0: VDSL2 link up, Path 0, us=6496, ds=16975
2000-1-1 0:25:53 Notice 104500 DSL activate succeed
Over at the DSLAM, all we can see for that re-sync from line noise in terms of seconds with problems is one ES and one SES, and an extra "full initialisation":
MA5616(config-if-vdsl-0/3)#display statistics performance 0 line-showtime cpe ever-before
------------------------------------------------------------------------------
Count of forward error correction seconds : 0
Count of errored seconds : 1
Count of severely errored seconds : 1
Count of loss of signal seconds : 0
Count of unavailable seconds : 348
Count of leftr defects seconds : 0
Count of the number of error-free bits passed(64kBit) : 0
Minimum error-free throughput : 0
Count of loss of frame seconds : 0
Count of loss of link seconds : 0
Count of loss of power seconds : 0
MA5616(config-if-vdsl-0/3)#display statistics performance 0 line-initial ever-before
------------------------------------------------------------------------------
Count of full initializations : 2
Count of short initializations : -
Count of failed full initializations : 0
Count of failed short initializations : -
------------------------------------------------------------------------------
That injected line noise caused large number of errors, but these are reported in detail as 'channel statistics' rather than as 'line statistics'. In the downstream (CO end) the noise which caused that re-sync is recorded as follows:
MA5616(config-if-vdsl-0/3)#display statistics performance 0 channel 1 co current-15minutes
------------------------------------------------------------------------------
Start time of this interval: 2013-06-07 03:30:00+08:00
Channel 1
The number of valid intervals in the interval table : 2
The number of invalid intervals in the interval table : 94
Total elapsed seconds in this interval : 402
Count of coding violations : 8
Count of corrected blocks : 34170
Count of encoded blocks : 37024
Count of uncorrectable blocks : 257
Count of atm cells : 0
Count of ptm packets : 82
Count of the number of retransmitted RS codewords : 0
Count of the number of retransmitted codeword that
effectively corrected a previously detected error : 0
Count of codewords that left the retransmit queue
without having been corrected : 0
------------------------------------------------------------------------------
Finally, just to confirm that the
ECI vg3503j (Revision /r) also sends a
Dying Gasp message. Although nothing is reported by the ECI's kernel:
Reset the DSLAM statistical counters first:
MA5616(config-if-vdsl-0/3)#chipset reset 0
Note: Please don't operating on port while chipset resetting, are you sure to continue? (y/n)[n]:y
From the ECI's kernel messages (to UART), up to the point that power is pulled:
[ 11.664000] Lantiq CPE API Driver version: DSL CPE API V4.11.4
[ 11.672000] Predefined debug level: 2
[ 11.704000] PTM 1.0.27 PTM (E1) firmware version 0.30
[ 11.708000] ifxmips_ptm: PTM init succeed
[ 19.880000] device ptm0.101 entered promiscuous mode
[ 19.884000] device ptm0 entered promiscuous mode
[ 19.888000] br-lan: port 3(ptm0.101) entered forwarding state
[ 20.812000] IPv6: ADDRCONF(NETDEV_CHANGE): ptm0.101: link becomes ready
[ 21.828000] br-lan: port 1(eth0) entered forwarding state
[ 21.896000] br-lan: port 3(ptm0.101) entered forwarding state
..
[ 94.576000] enter showtime
No loss of power seconds recorded by the DSLAM at this point.
MA5616(config-if-vdsl-0/3)#display statistics performance 0 line-showtime cpe ever-before
------------------------------------------------------------------------------
Count of forward error correction seconds : 0
Count of errored seconds : 0
Count of severely errored seconds : 0
Count of loss of signal seconds : 0
Count of unavailable seconds : 39
Count of leftr defects seconds : 0
Count of the number of error-free bits passed(64kBit) : 0
Minimum error-free throughput : 0
Count of loss of frame seconds : 0
Count of loss of link seconds : 0
Count of loss of power seconds : 0
Now the power plug is pulled on the
ECI (no indication of a
Dying Gasp message from its kernel):
And in the DSLAM logs we find:
MA5616(config-if-vdsl-0/3)#display statistics performance 0 line-showtime cpe ever-before
------------------------------------------------------------------------------
Count of forward error correction seconds : 0
Count of errored seconds : 0
Count of severely errored seconds : 0
Count of loss of signal seconds : 0
Count of unavailable seconds : 63
Count of leftr defects seconds : 0
Count of the number of error-free bits passed(64kBit) : 0
Minimum error-free throughput : 0
Count of loss of frame seconds : 0
Count of loss of link seconds : 0
Count of loss of power seconds : 29 (and rising)
So that confirms that both the
Huawei HG612 and the
ECI vg3503j (Revision /r) do send a
Dying Gasp message when the power is pulled from them.
cheers, a
[1]
http://www.broadband-forum.org/technical/download/TR-115_Issue-2_Amendment-1.pdf