Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2

Author Topic: leave modem on or off?  (Read 17885 times)

snadge

  • Kitizen
  • ****
  • Posts: 1450
leave modem on or off?
« on: June 05, 2013, 11:14:17 PM »

whats your opinion?

is it safe to turn off the modem and router?

or is it best to leave it on 24-7?

also, Im assuming someone from kitz wrote this in plusnet forums.... I dunno if Iam reading it right but the bit in bold sounds like a method to 'reset' the connection to ensure the best/proper speed profile for your line.. is this correct?

Quote
Unfortunately Plusnet can't get Openreach to do resets similar to ADSL, so it's a waiting game.

As you may have gathered, DLM on FTTC. can be aggressive, so as a general rule - do not turn off, reboot or disconnect the modem.
Should you ever have a real need to do that, the best method is to log into the Router, disconnect your PPP Internet session and then power down the Router. After about a minute power down the Modem and leave it off for at least an hour. Do this in daylight hours well away from dawn or dusk.
When you power up again wait for sync and all lights on the Modem to stabilise before powering up the Router. When the Router has booted, login and and click Connect to establish a PPP session.
There is no guarantee that doing that will improve the situation, it may stay the same or be slightly worse.

The best way to check the the sync speed of your connection is to run the BTw Performance test (ignore the red preamble except make sure no other programs are using the Internet) and at the end of the first run, click the Further Diagnostics button, enter just your Phone number and Run the Further Diagnostics Test.  The results will show the DS IP profile for the Line (ignore the US profile). On FTTC the Profile x1.033 = sync speed.  If you ever want to post the results here, just do a Copy and Paste of the results and post (no need to grab an image).

Do not rely on the ping result from the first part of the BTw Speedtest, it can be very variable and dependant on Tester congestion. Use ping ntp.plus.net from a cmd prompt. Pingtest.net can be quite reliable as well. But remember all testers can get congested a peak times and you should not rely on a single result. The same applies to speedtesters. You can get momentary peaks/dips at anytime so if you get an "unusual" result, run several tests. To get a true picture of the capabilities of your connection, run tests at off-peak times and try several testers to find which ones give consistent results for you.

One final point, the Current Line Speed at the member centre is initially set at the default value of 78Mbps for FTTC 80/20. This will update in due course to match the BT IP Profile, but if you want to ensure you get an accurate Profile from the BT Tester and ultimately the Current Line Speed, you need to login to the Router, drop the PPP session, wait about 30seconds and then click connect. This will initiate an update to the relevant servers. Do that will also mean you generally hop to another Gateway at Plusnet, which is something you may want to try if there are instances of persistent problems with slow downs or increased ping, just to check if it's Gateway related.

Logged
Aquiss - 900/110/16ms - TP-Link AR73

Ixel

  • Kitizen
  • ****
  • Posts: 1282
Re: leave modem on or off?
« Reply #1 on: June 05, 2013, 11:40:47 PM »

It's safe to disconnect/reconnect your router, but not the modem. DLM shouldn't intervene if it's just a one off for the modem, but a few times in a day might set it in motion. As a matter of course, though irrelevant for my line as DLM isn't functioning, I've set my ASUS RT-N66U router (with Tomato Shibby firmware) to automatically disconnect and reconnect the PPP session at 7:30am every day. If DLM were running on my line this would help ensure that my 'IP Profile' is kept in line with what my sync speed currently is. I prefer to keep the modem and router on 24/7 with a small desk fan underneath them blowing air upwards to keep both the HG612 and the ASUS RT-N66U nice and cool.
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: leave modem on or off?
« Reply #2 on: June 06, 2013, 01:59:46 AM »

Leave the modem on constantly.

Turn the router on at the start of the day and turn it off at the end of the day -- if that is what you are accustomed to do.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

ColinS

  • Reg Member
  • ***
  • Posts: 529
Re: leave modem on or off?
« Reply #3 on: June 06, 2013, 10:56:08 AM »

I think that B*Cat's advice is very sensible.  :)

If you have to power down the modem for any reason, it may help to appreciate the basis upon which DLM attempts to detect whether this was a user-caused resync or 'unforced retrain', or a 'forced retrain' caused by line conditions, as it tries to eliminate the former when determining the stability of your line.

Basically, it monitors the uptime in 15minute slots.  If a slot has some uptime, and then is followed by one with none, then clearly something has happened.  Either the user has powered it off, or the modem is having difficulty retraining ie regaining sync.  However, if DLM sees at least two successive time slots with no up time (i.e. at least 30mins) then it should regard it as user-initiated and ignore it.

One final point.  Asbokid has pointed out elsewhere that some modems have a last 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.

HTH
Logged

oldfogy

  • Helpful
  • Kitizen
  • *
  • Posts: 3568
  • If it ain't broke....... I'll soon fix it.
Re: leave modem on or off?
« Reply #4 on: June 07, 2013, 03:00:59 PM »

The main question here should be if it's a 'DSL/ADSL modem or Fibre optic.

As said earlier, DSL modems may not like being turned on/off especially in a short time span, mainly because you are likely to be getting your IP address changed with 'might' conflict with software you already have set-up, plus I believe your modem has to go through what is called a 'self learning' stage, before it is up and running to it's peak performance, but confirmation of that may be required from one of the many wizz kids here on the forum.

Whereas with Fibre optic (at least with mine) my IP address only gets changed maybe about once a year and as far as I know there is no self learning curve for it to go through.
With saying that, with my fibre optic from Virgin Media I used to turn my modem off at the end of each evening which I did for a few years without any adverse effects.

But I think you will find the general consensus is just to switch it on and forget about it, (unless you are having problems and need to re-set the modem.
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: leave modem on or off?
« Reply #5 on: June 07, 2013, 03:42:54 PM »

The main question here should be if it's a 'DSL/ADSL modem or Fibre optic.

 :hmm:  Hmm, as this is the forum for FTTC and FTTH Issues I think we can fairly sure of the xDSL type to which Snadge refers . . .  :D
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

oldfogy

  • Helpful
  • Kitizen
  • *
  • Posts: 3568
  • If it ain't broke....... I'll soon fix it.
Re: leave modem on or off?
« Reply #6 on: June 07, 2013, 09:25:42 PM »

The main question here should be if it's a 'DSL/ADSL modem or Fibre optic.

 :hmm:  Hmm, as this is the forum for FTTC and FTTH Issues I think we can fairly sure of the xDSL type to which Snadge refers . . .  :D
Considering my post above covers 2 different types of modem I'm sorry you feel you had to pull me up on the one issue that may not have been 100% relevant.
Logged

ColinS

  • Reg Member
  • ***
  • Posts: 529
Re: leave modem on or off?
« Reply #7 on: June 07, 2013, 10:54:45 PM »

As said earlier, DSL modems may not like being turned on/off especially in a short time span, mainly because you are likely to be getting your IP address changed with 'might' conflict with software you already have set-up, plus I believe your modem has to go through what is called a 'self learning' stage, before it is up and running to it's peak performance, but confirmation of that may be required from one of the many wizz kids here on the forum.
So, if you have a static IP address and have passed the 'self-learning' stage, then you can switch it off and on as much as you like with impunity no matter who your ISP is? :no:

Quote
The main question here should be if it's a 'DSL/ADSL modem or Fibre optic.
Isn't the main question whether an EU's broadband line is subject to DLM or not, and if so, how that DLM works?

Quote
But I think you will find the general consensus is just to switch it on and forget about it, (unless you are having problems and need to re-set the modem.
Surely the original question was
Quote
is it safe to turn off the modem and router?
« Last Edit: June 07, 2013, 11:02:59 PM by ColinS »
Logged

biohead

  • Reg Member
  • ***
  • Posts: 114
Re: leave modem on or off?
« Reply #8 on: June 07, 2013, 11:11:58 PM »

Considering my post above covers 2 different types of modem I'm sorry you feel you had to pull me up on the one issue that may not have been 100% relevant.

Don't forget, BT Fibre Optic uses VDSL signals - and is still therefore an xDSL modem. Your original post makes out that the Fibre Optic modem is NOT an xDSL modem, when it is. We're in the FTTC/FTTH forum, so we're not talking about Virgin Cable Fibre Optic, rather the BT Infinity Fibre Optic version via the phone lines.  :)
Logged

oldfogy

  • Helpful
  • Kitizen
  • *
  • Posts: 3568
  • If it ain't broke....... I'll soon fix it.
Re: leave modem on or off?
« Reply #9 on: June 07, 2013, 11:17:03 PM »

OK, point taken, and please forgive an old codger for trying to be helpful.

Edit, typo
« Last Edit: June 08, 2013, 02:38:12 AM by oldfogy »
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: leave modem on or off?
« Reply #10 on: June 07, 2013, 11:29:46 PM »

I think keeping the modem off is ok as long as its for a long period rather than doing it numerous times a day such as going on holiday, but cant be sure 100%, however I think its risky to leave the modem on with the dsl cable unplugged.  As it will tally up UAS.

Some also mentioned on tbb that if yoju cut the power from the modem rather than pulling the dsl cable it will send a dying gasp which DLM interprets as not to treat as line instability, but this is theory only.
Logged

asbokid

  • Kitizen
  • ****
  • Posts: 1286
    • Hacking the 2Wire
Re: leave modem on or off?
« Reply #11 on: June 08, 2013, 01:05:51 AM »

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:

Code: [Select]
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.

Code: [Select]
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.

Code: [Select]
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.

Code: [Select]
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).

Code: [Select]
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":

Code: [Select]
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:

Code: [Select]
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:

Code: [Select]
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:

Code: [Select]
[   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.

Code: [Select]
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:

Code: [Select]
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
« Last Edit: June 08, 2013, 01:52:43 PM by asbokid »
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: leave modem on or off?
« Reply #12 on: June 08, 2013, 01:34:27 AM »

OK, point take, and please forgive an old codger for trying to be helpful.

 :friends:
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: leave modem on or off?
« Reply #13 on: June 08, 2013, 01:49:44 AM »

  Asbokid has pointed out elsewhere that 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.

Okay, just got round to testing this with the HG612 and the ECI vg3503j (Revision /r) VDSL2 modems from Openreach.

<snip>

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.

A masterful series of experimental results. Thank you for sharing.  :)

I have another experiment that you might like to perform with one the Broadcom based Huawei HG6xx devices. Re-establish the CPE - CO link, with counters cleared, etc, make a telnet connection to the HG6xx device and then issue an xdslcmd connection --down command. It would be interesting to know how the MA5616 (DSLAM) reacts to that event.  :-\
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

asbokid

  • Kitizen
  • ****
  • Posts: 1286
    • Hacking the 2Wire
Re: leave modem on or off?
« Reply #14 on: June 08, 2013, 04:19:00 AM »

I have another experiment that you might like to perform with one the Broadcom based Huawei HG6xx devices. Re-establish the CPE - CO link, with counters cleared, etc, make a telnet connection to the HG6xx device and then issue an xdslcmd connection --down command. It would be interesting to know how the MA5616 (DSLAM) reacts to that event.  :-\

The DSLAM just records the (forced) downtime from that command under the counter heading of more UnAvailable Seconds:

Code: [Select]
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                          : 122  (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

For the sake of completeness (or almost, as the Ikanos Fusiv Vx180/185 chipset still needs testing),  the Metanoia MT3301/2301 chipset was tested.  The Metanoia VDSL2 chipset is found in the Draytek Vigor 2750/2850 and the Planet VC230.

The Metanoia does *not* send a Dying Gasp message.

Before pulling the power plug:

Code: [Select]
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                          : 36
  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

And a few seconds after pulling the CPE power. Note the lack of any Loss of Power seconds:

Code: [Select]
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

cheers, a
« Last Edit: June 08, 2013, 01:52:09 PM by asbokid »
Logged
Pages: [1] 2