On 02/05/15 04:49, Rich Brown wrote: > But I don't know enough about the physical characteristics of cable/dsl links to understand how they actually work, nor how fq_codel can (or can't) accommodate degradation.
I know a little about the DSL PHY behaviour. It is possible for line conditions to degrade, forcing the modems (i.e. the one in the DSLAM and the one in the CPE) to retrain. It is also possible that the newly-negotiated line rate is lower than the previous-one, so the end user would indeed see a reduction in the available bandwidth. However, DSL operators (the good-ones anyway) measure, log and manage the headroom between signal and noise on a per-line basis, so as to avoid this kind of instability. This is the case particularly for operators who also provide video services over DSL because retrains (which take quite a few seconds) kill the user experience. Take my line for example. I don't exactly know the length of my line to the DSLAM but it must be at least 1200m. Up until a few months ago I had 25.5Mbit/s down and 2Mbit/s up using VDSL2 without vectoring. But I know that my service provider, being in stiff competition with cable, has been silently upping the bandwidth of people's lines by first gathering stats on each individual line for a few months, and then, using a feature called dynamic line management that allows them to model the expected impact of increasing the rate of one line on the noise (crosstalk) experienced by the other lines in the same cable bundle, determine how far they can stretch each line. I now have 30M down and 2M up, still without vectoring, and with a training margin as reported by the modem of 9.6dB. (Before the speed upgrade I vaguely remember it being something like 14dB). So anyway: retrains are supposed to be very exceptional and indicative of something being wrong. By the way: another way for DSL operators to improve stability is to use interleaving. Specifically: interleaving helps to improve stability in the face of impulse noise at the expense of increased latency (which is why I mention it here). Jan _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
