O Canada! > Canadian > Canadian Broadband > Can line noise slow DSL-"speed" without changing sync rate?

Can line noise slow DSL-"speed" without changing sync rate?

Try the author of this post:


Speed slower than expected (Elite), d_l, 2007-Sep-16

...or try French because i don't understand your type of English...

reply to planiwa

reply to planiwa
Your not the only one bicephale lol sometimes i don't know where is going with is post lllloll

reply to l0thar

reply to planiwa
I am not sure that DSL modems "retrain" to a lower speed where line conditions deteriorate. I have personally never seen this happen.

With my old 3com, there were periods of the night where the SNR dropped to 3, but line stayed up, but seemed sluggish. I forced a retrain (the 3com had a command for that) and it synched at the normal 5mbps and the SNR rose back to 15

There's SRA, I think it was called, for ADSL2. Drop sync rate in response to bad conditions.

reply to planiwa
Hummm...

I've known bad days when my Siemens SpeedStream
would fall back from 5056 Kbps to 4032 Kbps while my
Thomson SpeedTouch kept trying 5056 Kbps without
end... Some brands/models are quicker than others at
gaining a connection by lowering the BitRates. In my
following example, it's obvious i had lost connectivity
looooooooong before the BitRate started to go down:


From the ground up!, Bicephale, 2008-Aug-23

...and even at that, i must point out my connectivity
wouldn't return until i started tweaking generously as
none of my ST5x6 units ever managed to settle... At
least my SS4200 did provide some connectivity time.



Imagine an intermittent situation where the disruption
takes place in short but strong bursts now!

reply to planiwa

reply to planiwa
Is there general agreement on the following statement?:

[1] "If the Profile Rate is maximal, and if the ADSL modem syncs at the Profile Rate, and if there are no re-syncs and no errors, then there is no need to be concerned over line noise problems."

and this one?:

[2] "If a chronic stateful speed problem can be fixed (or triggered) by a PPP reconnection, or is associated with spontaneous PPP disconnections, without disturbing the ADSL link in any way, the problem's cause is unlikely to be noise on the ADSL line."

. . .

It is often considered that 10 (CRC) errors / minute are the acceptable ADSL limit. (Bell will not open a ticket for a lower error rate.)

This may not sound like much, but it can reportedly reduce throughput by 15% according to d_l's chart (posted earlier in this thread): »Re: Speed slower than expected (Elite)

(FWIW, in the same forum (about a year later), J_J reported no degradation at all, with 420 errors / minute (and an SNRM of 9). This error rate should have resulted in no throughput at all, by d_l's chart. J_J's report was not questioned at the time: »Re: DSL Modem Issue - CRC Errors )

The (specification) BER limit of 10^-7 referred to in this paper: »www.jdsu.com/product-literature/···aper.pdf seems to allow 30 errors / minute (at 5 Mb/s), (and a throughput reduction to under 60%, per d_l's chart) before resync/retraining.

The JDSU paper seems to suggest that a BER of more than 10^-7 will cause resync/retraining. Line capacity and SNRM limits are mentioned as additional constraints

The errors vs. throughput chart (d_l) shows that 60 errors / minute could reduce throughput to 1/3. That's a Bit Error Rate of about twice the BER limit, assuming a fully utilized 6 Mb/s link. This would have been impossible to measure had the BER limit indeed caused resync.

. . .

So, the following view seems to be an oversimplification:

1. Modem syncs at rates based on current line condition (and, possibly historical data), limited by (NMS) Profile.
2. Increased noise can be compensated for (e.g. bit-swapping), so long as spare line capacity exists.
3. Beyond that, line noise causes transmission errors.
4. If error rates become significant (or noise limits are exceeded), the DSL link is broken, and ... continue from #1.

IOW: "Excessive noise causes errors and excessive errors cause re-syncs. (Lowering the sync rate until it reaches the line's level of stability.)"

Some practitioners appear to contradict this. #4, in particular, seems in question.

The details of #4 seem to depend on a number of factors, such as ...

a. what are the criteria for a sync rate change? (BER, SNRM, RCO)
b. can the modem train down without dropping DSL connection, and PPPoE connection?
c. (if so,) can modem train up, if line conditions improve greatly? (c.f. Dynamic Rate Adaptation)

. . .

One conclusion seems to be that the ADSL link, while characterised in the above cited paper as "a fixed quality, variable rate service", with a tolerance of no more than 1 bit error in 10,000,000, may actually degrade (TCP) throughput by 40% or more, before retraining.

. . .

One paper obscurely seems to allude to something similar: »www.actapress.com/PaperInfo.aspx···ason=500

"ADSL system was designed to operate with BER of 10^-7, but unpredictable noises may destroy data symbol, thus leading to errors in higher layer protocols. In TCP, a packet lost is interpreted as congestion in some point of the network. This packet lost can be recovered by retransmission, but transmission capacity is reduced due to congestion control algorithms."

. . .

At a typical rate of 900 700-byte packets / second on a 5Mb/s line, a BER of 10^-7 means 1 error every 1,800 packets, i.e. less than .06% bad packets. Is this likely to degrade TCP throughput by 40%?

Here is an interesting tutorial on Mathis' formula (which relates TCP throughput to packet loss, RTT, and MSS):

»www.silver-peak.com/assets/downl···Loss.pdf

It suggests that with a packet loss of 1% and an RTT of 100ms the throughput (limit) would be "nil". (Actually, it would be over 1 Mb/s.)

A more rigorous tutorial on the effect of packet loss on TCP throughput can be found here: »www.slac.stanford.edu/comp/net/w···ial.html and particularly: »www.slac.stanford.edu/comp/net/w···oss.html

Unfortunately I have not found anything comparably lucid on the factors and mechanism that determine data corruption in the DSL link, as a consequence of line noise. This is my intended meaning of the subject of this thread.

The BER specification limit of 10^-7 appears to be the only piece of solid information available on the subject thus far, along with references to SNRM targets and RCO.

. . .

Summary:

If DSL is indeed a "Fixed quality, variable rate" link, then it should respond to bad line conditions by dropping the bit rate so as to maintain the error rate at an insignificant level.

The specification Bit Error Rate (BER) limit of 10^-7 would appear to be this maximum error rate. This error rate is indeed insignificant. At the TCP layer it would amount to a packet loss of 6/100th of 1%, and no measureable retransmission speed-loss on a 5Mb/s DSL link.

Yet, several practioners seem to suggest that DSL links can produce error rates far in excess of the BER limit, without dropping sync. Some reported having measured error rates of 2-14 times the BER limit.

What this article seeks to show is that:

1. ADSL errors appear to be limited by the BER (design-quality-specification) limit of 10^-7.

2. Even an error rate 10 times greater would not result in a significant TCP throughput speed loss.

I invite anyone with claims to the contrary to substantiate their assertions, anyone with clarifying information to contribute it, and everyone to point out their perceived flaws in this article. Thanks.

Recommended Reading:

»www.commsdesign.com/design_corne···12801877
...... [Excellent comprehensive overview of DSL in context.]
»www.induteq.nl/portal/telecom_ic···ADSL.pdf
...... [(re-)sychronization scenarios]
»www.jdsu.com/product-literature/···aper.pdf
...... p.4 ADSL is a fixed quality (fixed BER of 10^-7), variable rate service.
...... .... as long as BER remains less than 10^-7, ADSL service requirements are met and synchronization will occur.
...... .... The data rate may be less than desired but it still meets specification requirements.
...... p.7 manual rate adaptation ... rate adaptation at initialization ... dynamic rate adaptation

Hi Planiwa,

Think whatever you want, it's your thread! As far as i'm
concerned, if there are no errors then there's no "noise"
for all practical purposes... Well, of course there's still
noise, actually, but i don't care for semantics right now.



If we agree that errors are a natural consequence of noise
then the shape of a long-term error rate curve depicts the
noise performance of my phone-line so that's good enough.

But your thread isn't about trouble-shooting, even if that's
what initiated your quest. By the way, i don't believe an IP-
based disruption excludes the presence of strong noise and
even less of short but strong intermittent noise bursts.

reply to planiwa

reply to planiwa
If he is getting enough CRC errors to affect performance, he should probably get switched to interleaved. Forward error correction should be able to handle most of the errors.

reply to DSL_Ricer

quote:

---

Also, in the case of large numbers of CRC errors, if the CRC errors are busty, you can have up to 32 CRC errors per actual dropped packet.

---

reply to Guspaz

One might wonder why you had to edit that
post and how many more times you'll do so.

reply to planiwa

said by planiwa:

said by Guspaz:

If he is getting enough CRC errors to affect performance, he should probably get switched to interleaved. Forward error correction should be able to handle most of the errors.

The question of this thread is: "Is it possible for a DSL link to produce 'enough CRC errors to affect performance' (without changing sync rate)?". I doubt it. I have shown evidence to support such doubt here: »Re: Can line noise slow DSL-"speed" without changing sync rate?

Thus far, no one has substantiated a claim that it is possible, and if so, how.

I recommend reading this very thorough and well-researched article in its present, expanded form:

»Re: Can line noise slow DSL-"speed" without changing sync rate?

It contains some lucid references at the bottom.

reply to planiwa
Hi Planiwa,

When the DS/US SNR Margin curves both drop to zero but not
long enough for the DS/US BitRate ones to follow do you think
threre's still connectivity or the MoDem is just slow to react?