Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 [2]

Author Topic: Why does DLM slow down an erroring line?  (Read 7413 times)

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Why does DLM slow down an erroring line?
« Reply #15 on: January 27, 2016, 07:25:12 PM »

15dB is the limit, and I don't think there's anything else it can do, no banding on 20CN.
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Why does DLM slow down an erroring line?
« Reply #16 on: January 27, 2016, 07:53:26 PM »

Thanks, will see how far I can rev it up tomorrow.  If I get get over 4000K I should get the 3.5meg profile.
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: Why does DLM slow down an erroring line?
« Reply #17 on: January 27, 2016, 09:19:48 PM »

Getting back to the original question, DLM does not intend to 'slow down a line'. 

Its aim is to reduce the rate of errors, which is achieved by raising the SNR margin.  A side-effect of the increased margin is that the modem will connect at a lower speed.

One reason it wants to reduce errors is that errors cause retransmissions, which can cause a delay noticeable as a pause or glitch, that is problematic for the user.  Also, TCP retransmissions are end to end which increases traffic on the entire network, potentially leading to unnecessary congestion and reduced bandwidths for everybody else.
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: Why does DLM slow down an erroring line?
« Reply #18 on: January 27, 2016, 09:40:21 PM »

Incidentally, tweaking the router is likely to be counter-productive, as it will lead to a higher error rate, and in turn to further punitive action by DLM.

One problem is that DLM includes a kind of hysteresis in its algorithms, such that the error rate to trigger a reduction has to be much lower than the error rate that triggered the increase.

What can sometimes help, counter-intuitive as it may seem, is to 'adversely' tweak the router so you get an even slower connection speed, but the error rates are also much lower.   With luck, DLM may interpret that ultra-low error rate as cause to reduce the target.   Even so, it can still take forever.    :(
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Why does DLM slow down an erroring line?
« Reply #19 on: January 28, 2016, 12:44:16 PM »

Incidentally, tweaking the router is likely to be counter-productive, as it will lead to a higher error rate, and in turn to further punitive action by DLM.

That's why I was asking whether it had any more nasties up it's sleeve.  If not, we're on 15dB target already so it doesn't appear there's any downside to tweaking.  It's been running like that since last Thursday and gives us just over 50% more application level throughput than leaving it slowed down even to the 12dB target.

Next update from OR is due Monday so fingers crossed the underlying fault will eventually be looked at.  On the other hand I had a call yesterday direct from Openreach asking me to confirm that the fault was cleared, the guy seemed quite taken aback when I said not, and he couldn't find any record of any further work being planned after the visit on the 18th.  In fact he didn't even have notes from that visit, and asked me whether it had in fact taken place.  I'm hoping the Plusnet have the correct information, and this caller was the one with the wrong end of the stick.
Logged

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: Why does DLM slow down an erroring line?
« Reply #20 on: February 06, 2016, 10:06:20 PM »

On SES:
My understanding was that a SES was a second-long period where the failure count (ie CRC errors) was really bad: 30% of all blocks.

Then, when a modem encounters 10 consecutive seconds that were all SES, the link is considered unavailable. The UAS counters then starts up.

My understanding of these terms predates ADSL. These terms were common in the old (but still digital) transmission mechanisms I worked with in the eighties, though they measured slightly different underlying failures.

On the reason for taking action on an erroring line.
The principle is purely to reduce errors, on the basis these are not helpful.

For UDP protocols, there is no protection. For most of us, that means anything streamed is lossy ... and too many errors make for audible and visible artifacts in video. Not a contender for "broadcast quality".

TCP protocols can cope with packet loss, but at the expense of slowdowns. See figure 2
https://blog.thousandeyes.com/a-very-simple-model-for-tcp-throughput/

What would you prefer? A 10% drop in line speed, or a 50%+ drop in throughput?
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Why does DLM slow down an erroring line?
« Reply #21 on: February 07, 2016, 07:48:26 AM »

It seems like everyone is just trotting out the standard theory which states some tiny number of errors will be horrifically bad.

What would you prefer? A 10% drop in line speed, or a 50%+ drop in throughput?

If not, we're on 15dB target already so it doesn't appear there's any downside to tweaking.  It's been running like that since last Thursday and gives us just over 50% more application level throughput than leaving it slowed down even to the 12dB target.

Quite a lot of web based streaming can also be done over TCP, many sites will have a range of different protocols available, pre-recorded video often uses RTMP (TCP) or just HTTP.

The trouble is, the DLM will take action against ES counts that have minimal impact on web browsing or even bulk downloads.
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Why does DLM slow down an erroring line?
« Reply #22 on: February 07, 2016, 09:38:32 AM »

I was trying to think why real world performance doesn't follow that theory.  To recap here are the error stats with the rough real-world speed test throughputs added ..

Target NM  Synch   FEC/Min  CRC/Min  ES/Hour  Throughput/Meg
   6dB      4256    2000     10-40     700         3.3
   9dB      3680    1000     10-40     600         2.8
  12dB      3104    1000      0-5      100         2.3

It would be interesting to have Wiresharked each of those, and given the current situation I might try and do that since I can easily put our line into a high error rate (making sure it's not long enough to attract the wrath of DLM of course).

In the absence of such decodes I can speculate on a few reasons.  One could be that the error numbers seem high but are actually low in percentage terms.  DLM "poor" threshold is given as 5>MTBE.   At around 300 pps that could be only one packet in 1500 that's being lost.   

Another factor may be that modern or even half modern TCP stack now set such high windows sizes that they can handle quite a few fast retransmits without slowing down at all.   

In terms of IP voice I'm not sure you'd notice loss of an RTP packet every few of seconds, though not ideal.
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Why does DLM slow down an erroring line?
« Reply #23 on: February 07, 2016, 09:43:37 AM »

Another anomaly is that it appears the targets are absolute error counts per unit time.  So slowing the line down may reduce those counts down to with acceptable values, while leaving the percentage data loss and therefore number of retransmissions unchanged.
Logged

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: Why does DLM slow down an erroring line?
« Reply #24 on: February 10, 2016, 10:08:35 PM »

I was trying to think why real world performance doesn't follow that theory. 

My one piece of good real-world experience came from my first FTTC line. On day 1, it synced at full speed, but encountered about 4% packet loss, permanently. Throughput tests (speed tests, downloads etc) came out with a speed of about 2-3Mbps lower than it ought to.

48 hours later, DLM intervened with standard FEC and interleaving settings, and solved the packet loss. IIRC, that knocked the sync speed down by 2.5Mbps. Those throughput speeds ... stayed the same..

As luck had it, the line needed to be regraded the next day, to change upstream from 2Mbps to 10Mbps. This entailed a DLM reset, so the line went through this exact pattern a second time.

It seems like everyone is just trotting out the standard theory which states some tiny number of errors will be horrifically bad.

Quite a lot of web based streaming can also be done over TCP, many sites will have a range of different protocols available, pre-recorded video often uses RTMP (TCP) or just HTTP.

My comment on video quality was focussed on the type of video BT cares about: their multicast TV service, where they need a quality that competes with Sky & VM. I'm sure they don't care about YouTube really, but catch up services are probably thought of quite highly now. This probably does help focus their minds nowadays.

Older ADSL DLM mechanisms were probably more focussed on keeping stable lines, reducing "truck rolls" as the Americans would put it.

Quote
The trouble is, the DLM will take action against ES counts that have minimal impact on web browsing or even bulk downloads.

The trouble is that DLM cannot distinguish what impact an ES count means, because it has no way to correlate it with a higher level. It could be highly significant, of little importance, or have no effect whatsoever.

BT are conservative, so will tend to err towards the "highly significant" more than otherwise.

Another anomaly is that it appears the targets are absolute error counts per unit time.  So slowing the line down may reduce those counts down to with acceptable values, while leaving the percentage data loss and therefore number of retransmissions unchanged.

Aren't the targets more about "time in error" per unit time? The use of "ES" takes away the dependency on the absolute error count, and turns monitoring into a study of how many bursts of errors occurred rather than absolute error.

IIRC, a burst of errors is likely to create one batch of TCP retransmissions, so the two correlate. I think it would be very hard to eradicate most ESs but keep the same volume of data loss.
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Why does DLM slow down an erroring line?
« Reply #25 on: February 11, 2016, 04:06:50 PM »

My one piece of good real-world experience came from my first FTTC line. On day 1, it synced at full speed, but encountered about 4% packet loss
DLM threshold of MTBE<5 sec is more like 0.06%.
Logged
Pages: 1 [2]