Correct approach for swapping modem/router to avoid errors

Not seen anything on here, so apologies if this has already been requested/answered.

I will be replacing my Business Hub 5 with a Billion 8800NL V1 in the next few days, and wondered if there is a correct procedure for shutting down/swapping equipment as to avoid the cabinet/DSLAM thinking there are errors on my line and perhaps making adjustments of a negative nature.

Any advice appreciated

Thanks.

To be honest if you switched the hub 5 off, unplugged it, plugged in the new device and turned it on then that should be fine. DLM won't worry unless it sees a fair number of reconnects.

Which is all I do, and then leave things well alone for a couple of days after changing hardware around.

Thanks both .... that's what I'll do then

For a one off that is fine. If there is a chance you may need to swap back soon after then the better way is:

Power off the modem.

Wait a minute or so, then disconnect from the phone line.

If you are using a separate router then power that down and disconnect from the modem.

Wait 5 minutes - power up the modem and wait a minute or two form it to fully boot and settle and if separate power up the router too.

When you are happy it has settled, then reconnect the modem to the phone line.

Wait another minute or so, and then reconnect devices or router.


The first step allows the modem to tell the DSLAM that it is going offline due to the loss of power which should be communicated to DLM and not acted on.

Rebooting offline reduces any start-up noise going back down the line.

A point to bear in mind also when powering down / replacing your modem / router:
Although virtually all modems / routers will generate a "last gasp" message on power down it is generally believed that the BT fibre DSLAM ignores this message and relies on BT DLM monitoring 2 consecutive, 15 min. time slots to deduct that the loss of synch. was a deliberate action / power loss by the end user and not an error driven loss which would immediately attempt to re-synch.
As such, I have always found it best on a planned outage or indeed a loss of power to keep the modem / router off-line for at least 30 min's. if at all possible to guard against any subsequent DLM intervention.

Probably not a big issue for a single power down / change out but certainly could cause an issue with DLM if a number of re-synch's were instigated in a relatively short period of time.
I have always obay'ed the 2 X 15 min. rule and never had any issues with unwanted DLM intervention.

Please don't take my word for this, visit the excellent "kitz.co.uk" web site and have a look at the tutorials on BT DLM principles & operation which explain this concept much better than I ever could.

Thanks all

Pleased to say I have successfully installed the Billion and a better RJ11 lead. No issues and it has given me a much better maximum sync over and above my 80/20 which I was pretty much getting anyway. Good to see that G.INP seems to have been enabled too on the downstream. Annnnnd ... my 5 static IP addresses are NAT'ting too, so very very happy bunny

I think I will be able to use the static IP that was assigned to the business hub as another usable IP, so have 6 available. Will test

Again, thanks v much for the feedback

Glad it all worked out well, good result.

You are priviliged to have G.Inp active on your line, makes such a big difference especially to DS ES rates, keeps DLM happy without the need for much more aggressive DS interleaving with it's associated latency penelty.

As you likely know, there is still an unresolved G.Inp software compatability issue with all BT ECI FTTC cabinets but recently quite a lot of Huawei FTTC cab. users have been loosing G.Inp for some reason and new users are not having G.Inp applied, I have been ADSL/VDSL converted for 7 weeks now and still awaiting G.Inp application to my line which is fully G.Inp compatable at both ends.

Thanks

My cab is certainly a Huawei and it's just a drive down the hill (about 280 metres)

Is G.Inp enabled on the line regardless of modem, or is it enabled as a consequence of a compatible modem being attached/identified? I've gained about 9000Kbps max sync by switching to the billion.

However, it appears from firing up DSLstats, vectoring isn't enabled.....

In your case G.inp is enabled because both your Huawei cabinet and your modem support it.

Vectoring is only enabled in a few test areas.

Edited by deleted (Wed 26-Jul-17 20:24:22)

Excellent, thanks

Yes. as BatBoy says you are lucky enough to be on a Huawei cabinet and your modem/router has G.Inp compatable software.

My understanding is that G.Inp is supposed to be applied to all VDSL2 lines, accepting the current issues with ECI cabinets, however there is a school of thought that G.Inp will only be applied to lines that due to their performance require G.Inp action (called re-transmission by BT )

I am of the belief that it is applied by default but certainly can not explain why some new users do not currently seem to have G.Inp applied and indeed some existing users are having G.Inp disabled ?

A DLM reset will removed G.Inp

Is that where OR reset, or can such a reset be caused by a user?

Where OR reset

In reply to a post by tiffy2:

Yes. as BatBoy says you are lucky enough to be on a Huawei cabinet and your modem/router has G.Inp compatable software.

My understanding is that G.Inp is supposed to be applied to all VDSL2 lines, accepting the current issues with ECI cabinets, however there is a school of thought that G.Inp will only be applied to lines that due to their performance require G.Inp action (called re-transmission by BT )

I am of the belief that it is applied by default but certainly can not explain why some new users do not currently seem to have G.Inp applied and indeed some existing users are having G.Inp disabled ?

Can you give examples of users disabled and/or never enabled on MWDS?

Can you give examples of users disabled and/or never enabled on MWDS?


Yes, me, MDWS ID tiffy, never enabled as stated earlier in this thread.
Other user I know of, kitz ID "j0hn", MDWS ID "minted", he has been waiting since February for G.Inp application.
There are certainly others who are on Huawei cabinets with compatable hardware & software awaiting G.Inp application.

MDWS users who have been de-G.Inp'ed other than by ECI cabinet issue:
Certainly more than the 10 currently showing on MDWS, all currently active users listing, circumstances not known, DSLAM reset etc., the site moderator, Tony Bailey could supply these details.

Regardless of reason for G.Inp de-activation why would DLM not re-apply G.Inp again ?

I can only speak for my line but I was enabled in March and it took several week for G.INP to be enabled. I then had a reset and it took a couple of days to be re-enabled again after the reset.

Just looking at the two MWDS lines you mention I notice that there are a lot of errors on your line but your upstream SNRM is 16db which I find very strange. Also minted has a lot of upstream errors. I also have some upstream errors but upstream G.INP has not been implemented on my line just downstream.

Maybe the upstream anomalies on these two lines are something DLM can't cope with and hasn't enabled G.INP downstream.

Might be worth starting a thread on Kitz and get someone expert to look over your MWDS graphs.