FTTC 10-day training

There are several threads around where people are being advised not to disconnect or re-sync during the initial 10-day training period, and that the DLM will seek out the best settings and possibly increase the speed during the period. One such advisor apparently being a BT FTTC installation engineer.

It has always been the case before FTTC that the above or similar advice is nonsense, even though peddled by BT Broadband support never mind all other ISPs. All the period does is set the MSR and FTR. It never of its own volition triggers a reconnection to achieve a sync increase.

I assume that it is also nonsense on FTTC. However there seem to be a number of reports on longer-installed FTTC lines of re-syncs occurring and the IP Profile rising almost immediately, after a previous fall, as though the DLM has been altered.

If the DLM in normal running has indeed been changed, then this could also be the case during the 10-day training.

Anybody actually know, as in quotable specifications, as opposed to what have been told by someone else, even a superior in BT, who possibly has it wrong?

SIN 498 sayeth :-

"DLM constantly manages lines to maintain a target stability. It does this for as long as the product exists.

At provision, the line is put on wide open profiles, allowing downstream line speeds
of up to 40Mbit/s, and upstream line speeds of up to 2Mbit/s or 10Mbit/s depending
on the upstream product option selected.

On the first day of operation, DLM will intervene if severe instability is detected.
Otherwise, DLM will wait until the day after provision before intervening, provided
that the line has been trained up for at least 15 minutes during the preceding day.
If DLM intervenes it will set a capped profile with a maximum rate and a minimum
rate, where the minimum rate is set at approximately half of the maximum rate. The
purpose of the minimum rate is to ensure that the line does not train at a rate which is
significantly below the level the line should be able to achieve. If this happened, then
the line is likely to remain at a very low rate till a re-train is forced by the user
powering off the Active NTE."

if that helps

SIN495 points to a fundamental difference in the line speed flagging arrangements :-

"Unlike other WBC access technologies, WBC FTTC accesses use the PPP (“Point-to-Point
Protocol”) session establishment to inform the BT Wholesale BRAS of the Openreach line
rate. It is therefore essential that the PPP session is re-started every time the VDSL line retrains. To ensure this, the PPP / L2TP timeout values must be set to less than 20 seconds."

previously the BRAS profile used a speed value sent by the DSLAM on resync which resulted in the issues with missing data and volumes of transactions leading to rate of change constraints. Perhaps the new approach will have less data and a more reliable means of transmitting it - it is at least a difference between FTTC and "normal" that would explain instant profile changes.

In reply to a post by RobertoS:

However there seem to be a number of reports on longer-installed FTTC lines of re-syncs occurring and the IP Profile rising almost immediately, after a previous fall, as though the DLM has been altered.

If the DLM in normal running has indeed been changed, then this could also be the case during the 10-day training.

Anybody actually know, as in quotable specifications, as opposed to what have been told by someone else, even a superior in BT, who possibly has it wrong?

Can't help with quotable specifications, but I do have some hard data which might be useful.

When the BQM or router log indicates a loss of connection I always run a BT speedtest to see what it's done to me this time, and log the results:

Installed 24-08-10 profile 38717

Solid connection until:

09-12-10 29489/7449  profile 33598     (Xmas lights and central heating systems?)
11-12-10 30529/8037  profile 33865
17-12-10 (failed to run) profile 33598
18-12-10 27932/7588  profile 33598
20-12-10 29359/7073  profile 33598
21-12-12 31313/7969  profile 33464
22-12-10 30472/7561  profile 33730
23-12-10 28998/5284  profile 32658
23-12-10 30507/7829  profile 33464
24-12-10 30690/8017  profile 33723
05-01-11 30969/8133  profile 33730
05-01-11 30510/8148  profile 33578
06-01-11 30117/7924  profile 33464
07-01-11 30622/8088  profile 33730
07-01-11 (failed to run) profile 33464
07-01-11 (failed to run) profile 33588
08-01-11 30547/7907  profile 33585
12-01-11 30717/8006  profile 33865     (accidental unplug)
16-01-11 33881/6063  profile 37333     (No more Xmas lights?)
16-01-11 27935/8046  profile 35372
18-01-11 33951/7710  profile 37232 (21:03)
20-01-11 33911/7836  profile 37232 (02:31)
20-01-11 33504/5478  profile 37523 (19:13)

The resyncs can happen at any time of day or night, no obvious correlation with when it might be caused by a noise event.

It looks to me as though the DLM is forcing an occasional resync "on spec" to see what happens... and also indicates that the granularity on the profile is very fine!


edit- another data point added, and some recent times of drop from router log.

Edited by billford (Thu 20-Jan-11 21:35:58)

In addition to speed I noticed my latency jumped from 24ms to 38 ms on day 1 (day 0 being install day).

I had assumed this was DLM trying interleaving. Am hoping it will switch it off soon.. would love to know the algorithms used to determine this.

What those speed tests don't show (but the BQM does) is that when the profile dropped on 9-12, the latency went from ~10msec up to ~20msec; I made the same assumption about interleave. When the speed went back up on 16-01 the latency also went back to ~10msec.

In reply to a post by planetf1:

would love to know the algorithms used to determine this.

Wouldn't we all

Two posts giving exactly what I was wondering about re the profiling, thanks yarwell.

I need to think further and probably read the SINs.

Thanks Bill for the two posts. You of course were one of the cases I had in mind re on-going DLM behaviour, but seeing the data in list format is great.

Thanks planetf1, that's useful as well as the other two posters so far.

Bill, please can you check the next few PPP Session expiry and start times and see if there is a correlation?

Obviously there should be with the start time, what I'm wondering is whether the session expiry time is relevant.

Sorry Bob, not sure what you mean?

AFAIK my PPP sessions don't "expire", they just get disconnected... and all I can get from the router is the time of disconnection (but not the cause) and the time when authorisation is successful and I'm back in business (usually takes about 70 seconds or so).

does the PPP session uptime tend to match the DSL uptime or can you not see the latter as its on the Openreach modem ? I think I would be buying my own VDSL router to learn about it, when FTTC comes here in 2020

In reply to a post by yarwell:

does the PPP session uptime tend to match the DSL uptime or can you not see the latter as its on the Openreach modem ?

There are three LEDs on the modem, one of which is for power. If I can't get the information from them, I can't get it at all


eta- if I happen to be at or near the computer when the link goes down I can see the DSL LED flashing as it retrains, of these occasions (maybe 70% of the times it drops) I think only once have lost it without a retrain, ie just a PPP drop.

Edited by billford (Thu 20-Jan-11 19:35:30)

Ah right . Sorry about that.

I was thinking of it in ADSL router terms, where you can see the PPP session start time and expected expiry time. So knowing those you would know what the lease length was and if the next session start time was earlier than expiry due time it is some at the moment unknown trigger.

On O2 with Netgear routers there used to be a problem where the lease did not renew when it should. the result was that the PPP session dropped and that was the end of things, although there was still sync with the exchange.

With what yarwell came up with, about the new profile update method and the 20-second trigger on the PPP ... and so on and so on. Just looking for seemingly unrelated events that might add up to something.

Wouldn't that lease time refer to a dynamic IP address? I'm on a static IP.

Admittedly that doesn't stop it having a lease period, but I've never seen any evidence of it- these things usually show as a brief spike of lost packets on the BQM and I've had weeks go by on occasion with nary a spike.

it wasn't a lease time it was a PPP timeout - making sure it was short enough to catch a resync and renegotiate, rather than keeping the PPP session up.

Ah, OK, thanks... I can't now be certain, but I don't recall any of the ADSL routers I've had giving that information anyway