What's this "re-connection capping" business all about?

[gatekeeper]

I've noticed that contributor ardsar, in his recent 8800 and 8900 topics relating to operational acoustic noise and ever-falling SNR, has been concerned on occasions to:

".....maintain a lengthy uptime in order to reset the DLM capping that Openreach has applied to my line".

and

"...Every disconnection risks having my line speed capped by Openreach ........ it took 12 days continuous uptime to get it removed".

and

"My line got banded".

What's this all about? Is it the general case that there's a limit to the number of times that you can disconnect or restart the line via the router before Openreach locks the line at a certain speed, or is ardsar referring instead to some specific feature of HH5 operation?

In the days of ADSL Max, there was said to be a limit on the number of times you could restart a router and re-negotiate a new target SNR all in one session. Apparently, the DSLAM at the other end of the line could get screwed up if too many restarts took place within a given period. If you exceeded the limit, the line speed was locked and you then had to wait 24 hrs before you could try again. In practise, I used to restart my router many times while experimenting with target SNR values but never encountered any lockout.

These days, is there any such limit with VDSL operation - or with ADSL2+, for that matter? Or is the capping or banding that ardsar's mentioned something particular to just his account and the HH5 that he's referred to?

[ardsar]

All you need to know about the DLM process can be found here.

http://www.kitz.co.uk/adsl/DLM_system.htm

This is a great website for both support and technical issues.


The two main parameters in use are:-

•MTBE (Mean Time Between Errors) = Connection uptime / Errors or Code Violations i.e. Eroded Seconds or Serious Eroded Seconds
•MTBR (Mean Time Between Retrains) = Connection uptime / No of retrains i.e. number of times the line is dropped in a given period.

The events used by the DLM system are:
•Total 24hr ES & SES
•Total 24hr Full Initialisations
•Total 24hr Failed Initialisations
•Total 24hr Uptime
•Total 24hr Unforced retrain count.

The number of events allowed depends on the stability profile selected for the line (determined by the ISP).

Depending on these figures, DLM will intervene by applying interleave, G.Imp or eventually banding.

Rapid line retrains will also result in additional action being taken. My line got banded thanks to using an ASUS router that was so unstable it kept dropping the line.

[gatekeeper]

Thanks. There was a period a year or two back when I used that kitz site from time to time but I've since got out of the habit. I'll take a look again, in particular at the page you've indicated.

One thing to bear in mind when you're reading material off of kitz - or any other website dedicated to the technical aspects of routing and the Internet - is not to always gayly assume that the information given there is up-to-date. I made that mistake once and subsequently got my router's operation into a bit of a mess when I later discovered that kitz's published figures on interleave depths (ID) for ADSL were no longer relevant. Openreach had in fact, in the interim, done away with distinct sets of values for ID, now standardising on just the odd one or two for ADSL.

That said, I notice from the various screenshots recently posted by contributors running VDSL, that, with VDSL, IDs can range widely. Whether the user has any control over ID on VDSL I don't know. Perhaps ID values are determined now entirely by the DSLAM?

The point I'm feebly trying to make is that Internet networking is forever changing and advancing, and so the rules concerning the configuring of certain features can quickly get out-of-date. Websites often don't revise their information to suit. So, are you quite convinced that the rules about forced retrains and the like, as read on that site, do actually correspond with current and common experience?

[gatekeeper]

Yes, that kitz webpage to which you've pointed is very informative. 'Filled in some bits of knowledge I didn't have.

Under 'Training & Stabilisation' it states that FTTC doesn't have a training period. Hmm, that's news to me. And then strangely, a bit later, it says 'Additional line monitoring will also be performed if the system detects 10 retrains in any 1hr period'. (Mind you, the result is only 'monitoring'; furthermore, it's not explained if this applies just to ADSL).

Pertinent is that Kitz say in their final paragraph on that page that a new system of central management was undergoing testing in 2012 and that in due course BT would probably change to an Huawei U2000 setup. This is, in my view, indicative of how some of this information can become out-of-date. I notice that the webpage was last updated in Nov 2014.

In the wider context, the fact that information concerning the line parameters that are measured by these equipments can in due course become outdated, or even irrelevant, may have implications for home-user applications which monitor the line and, apparently, give accurate statistics.