In reply to a post by simon194:

FTTC DLM appears to force resyncs but it only takes 20-25 secs to resync and most of the time they occur in the early hours of the morning.

I use my connection a lot then (do a lot of work during night remotely), also even if I am not using I monitor things with my connection and it will be an annoyance if it drops every night.

With that said tho obviously I am aware this may not happen at all and it may be that I will be in the threshold where DLM leaves me alone, if the line is unstable and DLM keeps changing things then I will ask to go down to 40/10 which provide me with a buffer hopefully as the estimated speed is much higher.

mine resynced 7 times around 1 am now on interleave

When my connection resyncs "on the fly" it usually only takes 16 seconds.

This is too quick to be spotted by my ISP & BT as a disconnection, a new PPP session is thus NOT initiated & BT's IP Profile is NOT updated.

As my ISP (Plusnet) also uses a line profile (a.k.a. current line speed - slightly lower than BT's IP Profile), that is NOT updated either as they are only informed of any changes whenever BT's IP Profile updates.

Hopefully someone can give me some further info on this, interleaving in particular. Had 80/20 service for 3 months (ADSL24), first two months using laptop connected directly to the modem and got full speed and 11-12ms latency to the bbc. Installed router middle of October and noticed the ping varying by a couple of ms every packet, didn't think much about it and carried on. Noticed ping had gone up and thought interleaving had been applied as router was on and off a few times while my consumer unit was replaced, speeds still as good as before.

Worried about the variation in ping I tested the wan port and it was flapping by a couple of ms even on lan so I replaced the router (TP-Link 3600) with a known good Netgear. Spoke to support and they said BT will not reset the interleaving as a lot of people have found out. Ping is rock steady on the new router so clearly an issue with the Tp-Link.

I've been running a BQM and noticed what I think is a resync today, it seems like a new PPP session is required to update the profile. My question is - as I have no issues with profile speeds, will creating a new PPP session help with my interleaving or should I leave things as they are and hope for the best?

ECI modem on ECI cab so no stats for me and don't want to upset DLM any more by trying a HG on it, BQM link below if anyone can advise on if that is a resync at 1500 and should I create a new PPP session in the hope that interleaving will be updated back to normal?

http://www.thinkbroadband.com/ping/share/71a231556d5...

Many thanks.

This is apparently taken from a BT chief engineer's quarterly publication:-

"Each night, the DLM system uses the previous 24hrs of circuit performance data to ascertain whether the mean time between errors or excessive retrain thresholds have been breached on a line. If they have, DLM will place rate caps, interleaving or both, on the line to improve error rate, stability, or both, by the change of its line profile."

DLM controls the interleaving and the sync speed. These are both decided between the cabinet and the modem.

Resetting (disconnect/reconnect) the router to force a new pppoe session will ensure the IP/BRAS profile is reset to match the sync speed. It won't have any effect on the interleaving, or the sync speed.

If you don't have interleaving, the first hop on a tracert will be somewhere around 5/6 ms. Anything above that is due to interleaving. Even though I am on interleaved at the moment (around 8ms extra), a bigger cause of latency is BT's routing from the south to London via Sheffield the hops north and back south add around 10ms extra on the bbc ping between them).

All 3 spikes look like resyncs, although the third is obviously of lower duration.

As another posted stated, a new PPP session (as requested by the router, or by a direct PC connection) will have no effect on the need for (or amount of) interleaving or FEC.

As Bald_Eagle stated, DLM tends to look at the average error counts over the last 24 hours, and the number of resyncs, and decides whether it needs to limit your connection speed, or add interleaving.

However, it most certainly isn't as fast at taking things away again when any problems disappear. You can expect to wait for between 1 and 4 weeks for that to happen - so patience is required.

And even then, there's no guarantee. My first line got interleaved after 48 hours, and it stuck forever.

Which is clearly in their favour not those customers who are unduly affected by it, all the more reaon for an opt out from DLM to be provided

And IMO a vaild reason not to bother with FFTC If you are unlucky enough to have a problematic D' side pair be it affected at times by an outside source or even a developing line fault & several weeks is a too long,

I thought this FTTC malarky was supposed to be advaced tech?

Edited by tommy45 (Wed 28-Nov-12 04:05:08)

advaced tech can mean different things.
One is using newer, robust techniques. FTTP is an example of that.
Another is pushing old techniques to (or slighty beyond?) their natural limits. FTTC is an example of that.

In reply to a post by tommy45:

Which is clearly in their favour not those customers who are unduly affected by it, all the more reaon for an opt out from DLM to be provided

Who is the "they" that this is in favour of? Certainly there are benefits to end-users, Openreach, Wholesale, ISP and the internet at large.

The only dis-benefit to most end-users is when they don't have a tip-top speed that gives them bragging rights. Some end-users get hit a little heavily - and here I agree that BT have a tendency to rely on DLM rather than fix the line - but it is a small number of users, and certainly not worth cutting off your nose to spite your face.

DLM is a part of the advanced tech that wrings more & more speed out of our copper infrastructure. The next type of advanced technology in the DLM school is known as vectoring, which ought to put back the speed that is otherwise lost from crosstalk. I'd expect that to have direct effects on both aspects contributing to lower speeds: higher SNRM values *and* less need for FEC.

And IMO a vaild reason not to bother with FFTC If you are unlucky enough to have a problematic D' side pair be it affected at times by an outside source or even a developing line fault & several weeks is a too long,

You really do want to chop that nose off, don't you?

The advantage of cabinet-based FTTC here is that it automatically reduces the amount of line that needs to be trouble-shooted to find the problem. The means it ought to be easier to locate than with an exchange-based solution... provided you can get an engineer onto the problem in the first place.

I thought this FTTC malarky was supposed to be advaced tech?

There's always an element of the community that will regard *any* advanced tech as suspicious and worthy of criticism, no matter what good it brings. And not just in telecoms.

In this case, why blame the advanced tech of FTTC when the issue you have is with the planning & operational rules of a telcom company?