Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[NewtronStar]

Twice in a row I wouldn't call a coincidence myself, but my line isn't faultless. I don't know where you assume that, as now I'm back on fastpath I'm currently getting quite a lot of ES per hour, quite a lot this evening infact. I've never known my line to be this bad on fastpath before, only things have changed are the new firmware update, the MK2 faceplate I recently bought, and a new ADSLnation Pro+ 0.5m cable. It will be interesting to see if DLM puts me back on interleaved again, despite me reducing the sync speed in order to increase SNRM.

From what I see you have what I call a perfect FTTC line, I get about 20-30 Errored Seconds per hour with a Max Attainable of 34000 kbps you have capped your own download rate and most users complain because the DLM has capped there download rate, I don't mind people flaunting there higher specs's but what I don't like is you seem oblivious that most FTTC customers don't have excellent lines like yours and you will need to take that into consideration to when giving out the tweaks details

Apart from that I'm just jealous 

[Ixel]

From what I see you have what I call a perfect FTTC line, I get about 20-30 Errored Seconds per hour with a Max Attainable of 34000 kbps you have capped your own download rate and most users complain because the DLM has capped there download rate, I don't mind people flaunting there higher specs's but what I don't like is you seem oblivious that most FTTC customers don't have excellent lines like yours and you will need to take that into consideration to when giving out the tweaks details

Apart from that I'm just jealous 

On the contrary, I know two people locally who have terrible speeds due to their distance from the cabinet, I sympathise and have tried to help them get the best speed possible out of their connection. I don't intend or mean to show off my 'good quality' line, even though I don't feel it's good quality in regards to errors, it does however produce a speed that a good percentage wouldn't get and for that I'm very greatful.

Anyway I feel as if my presence on this forum appears to be more of an annoyance or appears to be encouraging something that's not nice, so in the best of interests I'll avoid posting.

[Chrysalis]

I have had 2 ES over past 10 days. Not 2 ES per day 2 total.

That's very odd. I'd have expected DLM to switch you by now then :s.

A DLM with good logic yes.

you have ten days to go and your impatience will be your downfall, and trying to fool the DLM is near to impossible and Yes Ixel thinks he's got it cracked but would say it's just pure conincidence, his line is basically faultless he would have been moved to fastpath even without the so called tweaks so I wish Ixel would do some more re-search into his findings with some Graphs to back it up with, as your are leading some members into a false path on FTTC.

DLM isnt a static 14 days.  In the past I have recovered after 2-3 days.

and I am waiting however I can form an opinion a 14+ day wait is ridiculous for a one off issue.

Also to note I havent tweaked my modem as I said I am waiting, I believe what he did will help people stay on fast path assuming the DLM doesnt penalise for a high snr margin (why would it?).  The DLM isnt some super intelligent being, its a software program fed with parameters, software can be manipulated and is done so frequently.  All the tidibits made public about DLM indicate it works on # of retrains and # of errors on the line.  Increasing the noise margin on a line via capping its sync speed will decrease both retrains and errors.  So its logical both him and les are correct.

It be interesting to see which comes first, the engineer plusnet are trying to arrange (BTw system broken) or my DLM recovering.  Also my line is still banded to 74mbit for a year now, from a fault I had a year ago, it never reverted to 80 banding.

[ryant704]

Chrysalis I waited over a 89 day sync and then 37 days. I had enough and phoned BT and got an engineer, luckily I know the engineers in the area. Requested a DLM reset and he did it for me...

[Chrysalis]

wow you patient

Something weird is happening as I think I was banded to 54 a few days ago and now 40 since this morning.  the error rates are now extremely low, no retrains (except DLM early morning).

[les-70]

   You are all making a newcomer to any DLM (I was always on llu on adsl2+) quite concerned.  So far the only resyncs on my line have been ones caused by me but as more people get FTTC on my cab I expect the DLM to get more interested in my line as time goes by.  I am restricted my speed to keep it that way as I also dislike interleaving.

  I had a fault on my adsl2 line card and it stopped syncing at all at its normal ~17Mb/s on fast path and it was then enabled to work at 8mb/s but inteleaved until the line card was changed.  8mb/s initially felt unresponsive on web pages but I asked for it to moved to fast path.  With that change I could hardly notice the difference between 17 and 8.  Nothing like the change from fast to interleaved at a level 64.

  Is there any description of what the FTTC DLM looks for and does? I have only found guesses and bits on ADSL DLM in limited trawls through the forum posts.

[ryant704]

It's entirely different, BTW DLM worked off noise and target margins. The OR DLM seems to work off Banding and Interleaving/Fastpath.

[Chrysalis]

I am also of the view the BTw dlm was better, although many disagree with me.  But the BTw DLM seemed to (a) tolerate more before taking action, (b) could be overriden/reset by the isp without an engineer and (c) usually it buffed up snrm before trying to interleave.  Whilst the Openreach DLM has a auto recover mechanism its very slow, where people can end up paying for a gimped service for several weeks because DLM is programmed to be extremely cautious.  The only thing better about openreach DLM is it doesnt also interleave upstream like BTw used to.  So the interleaving is less severe.  Of course LLU without DLM was brilliant but BT just dont get it in that regard.

Les as to the differences these are my observations based on my line and information around the web.

BTw DLM more sensitive to disconnections, Openreach less sensitive.
BTw DLM less sensitive to error bursts, Openreach 'much' more sensitive to line errors.
BTw DLM will usually increase snrm to stabilise a line before applying interleaving, Openreach DLM will typically apply interleaving before trying banding.
BTw's snrm changes can be overriden by a modem, Openreach's banding cannot be overriden by a modem.
BTw DLM can be reset by an isp, the fast/path interleave status can be set to auto, fast path, or interleaved by an isp.  Openreach DLM the isp has no control over the DLM other than configuring the stability profile, an engineer is required to order a DLM reset.

There is very little known about isp's changing stability profile's, it seems it can be done on a whim, they place an order and it gets actioned by openreach, what isnt known is if a profile change resets DLM or not, if it does then the isp's do have a way to reset DLM but none so far have tried to take this route, eg. changing a line to stable profile for 24 hours to reset DLM, then switching it back to speed.

[les-70]

   Thanks for the advice on experiences with the OR DLM.    I would not complain about about line errors being the main criteria, that may well be best. 

  That said my impression here is that many line errors are quite intermittent and probably correspond to rarer very nasty rf spikes that take a lot of snr and thus speed drop to control.  I have not had much experience of interleaving and can't comment on how effective it is.   It would interesting know what crc/hour people on fast path actually get, there may be an upper bound to values found on fast path lines that gives some idea of what provokes the OR DLM. It may however be bursts that cause real traffic issues that trigger the DLM. That would also be quite sensible even if frustrating when the bursts are very rare but enough to trigger action.

  It also is pity we don't know more about the fast/standard/stable OR DLM option that I seen discussed on TBB forum. They might just vary in the aggressiveness of intervention or they might differ in favoring fast path or interleaving c.f banding.  Without knowing what they do it is not worth trying to request one or the other.

 

[Chrysalis]

plusnet staff have stated the differences on the profiles are the trigger points, the example they quoted was 10 disconnections a day on speed vs 2 on super stable, this was an example quoted tho I dont think is actual figures.

Some noise bursts might take a lot of snrm to control I dont disagree, my issue is that DLM can over react big time for very short term problems.  There is a difference between ongoing permanent noise and one off interference.  The latter can still cause a line to be slowed down for several weeks.  Plus DLM waiting till 3-6am the next day means it will often react too late to temporary problems.

My ideal solution is no DLM or at least optional DLM.

But a better DLM would maybe work like this.

It monitors errors at 15 minute intervals.
If excessive CRC errors (particurly SES) it makes changes to the line immediatly, applying a higher snrm, or banding Xmbit below current sync speed.
If still a problem, it tries even more snrm.
If still a problem it then applies interleaving.
It priorities interleaving the 2nd time if the extra snrm decreases sync speed below 15mbit/sec.
when DLM intervenes it sends a automated alert to the local openreach office in the area to report a line fault, openreach are then duty bound to bring the line back to fast path unbanded conditions, if they fail the end user has a choice of free opt out of contract or ongoing fixed fee £10 month discount until the fault is fixed, in other words interleaving is treated as a temporary fix to a problem not a permanent fix.
If the line calms down, and its the first instance in a month it will wait a maximum of 36 hours and then recover the line to full performance (or at least up one performance level if multiple actions have been taken).  This is a guarantueed recovery time so isp rep's can assure end users it will happen, not the draw out of the hat as is now.
If the problem comes back, same as before, react within 15 minutes, but the recovery time increased to 5 days, again a guarantueed time so end users not told to "just wait" for an indefinite time.
If the problem comes back a 3rd time within a month after a 5 day recovery then use the current slow tiptoe approach as it at that point can be considered a ongoing problem.
After a line has been problem free for 1-2 months reset the counter so if a new problem occurs its considered a "first time" again and treated as such.

Even the above would be frustrating tho eg. if you have a short burst of errors that lasted 5 minutes once every 3 weeks, that could lead to a permanent interleaved line.

[kitz]

   So far on my FTTC connection running at 80/20 I have estimated that a 1db change in the reported "over all" snrm on HG612's corresponds to a drop of ~4Mb/s in the attainable speed.  I wondered if people achieving syncs of either 80/20 or 40/2 or 40/10 could report their downstream snrm's and max attainable speeds. Assuming all are on a 6db target snr this should allow the relation between snrm and speed to be refined.  Adding overall downstream attention may also be of interest but I am sure sure that it is a reliable quantity.   That is just the three numbers max down/, snrm, and attn.   

    Thanks in advance for any inputs.


 p.s.  Please let me know if this has been done before!

Sorry Im late coming in with this, but PC has been sick over the past month due to an issue with the graphics drivers, so not been able to get them sooner. 
Anyhow I think this is a good suggestion and Ive put together some stats for this topic.
It should also be bourne in mind that I had a line fault in my early few months.   These arent my best/worst.  I just took the stats from the first plink of that day.

Code: [Select]

Date Max Up Max Down SNR up SNR down

19/07/2013 35730 101448 15.8 11.8
19/08/2013 34811 105652 15.4 12.8
19/09/2013 31944 96096 14.5 10.3
19/10/2013 32271 95400 14.8 10.1
19/11/2013 30385 88552 12.8 8.3
19/12/2013 30794 88540 13.1 8.3
19/01/2014 30833 86436 13.1 7.7


Signal Atten  July 2013 and now

Code: [Select]


U0 u1 u2 u3 d1 d2 d3
0.8 17.7 28.8 N/A 11.1 24.4 38.4
0.1 17.7 26.4 N/A 10.4 23.1 35.7


[Chrysalis]

no callback from plusnet when they promised yesterday I am started to become tempted to try this to fasttrack it.  Then I realised the line is already throttled to a very low sync now anyway.  My attainable is still the same.

[les-70]

  @Kitz  Thanks for those stats they are very much in line with those found already and at the 4Mb/s per db corresponding to all or almost all tones in use.  See reply 3 for my conclusions on the relationship.


  I don't expect my line to stay at 80/20, I was first here on FTTC and at the moment I think there are only about 4 connections on FTTC on the cab and with just that my attainable has dropped from 108 to 85. It looks like you have had similar drops.  All things being equal and guessing FTTC take up in my immediate vicinity I have calculated that I will end up with an attainable of about 70Mb/s or a bit less. More or less at or below the BTW lowest estimate for an impacted line.   To stay on fast path I am interested in keeping the DLM  out of that capping process.
   

[Chrysalis]

yeah kitz you getting close down to 7.7db snrm now.

Incidently plusnets line checker does not detect crosstalk on my line but as I said before without vectoring technology deployed I am not sure how they could reliably detect it.  I gone down to 69 attainable on fast path from 110, so the BTw checker states I dont have a fault detected and I dont have crosstalk, so unexplained loss of 40mbit of sync signal.

for me plusnet still cant book an engineer

[kitz]

It's surprising the impact x-talk can have.   Certainly more than I was expecting, and I'm not even sure if some of the figures have been higher than bt anticipated.

I wasn't 1st on my cab and there were quite a few already active (I'm port 25 iirc) yet as you can see I've lost appx 20mb in 6 months (my first quoted figure above perhaps wasn't the best as i was in the midst of a line fault at that time), so I should imagine those first on my cab will possibly have lost a lot more.  None of the lines served via my cab will be long lines.