[RndTbl] Request confirmation...

Adam Thompson athompso at athompso.net
Tue Jul 13 23:32:36 CDT 2010


Heh.  "FEC" = Forward Error Correction.  MTS uses it.  They probably
shouldn't in most cases, or rather: not so aggressively.

For every 100 bits of user data your DSL modem transmits (or receives), it
also sends anywhere between 1 and 50 bits of EDAC (error detection and
correction) data.  The particular schemes used in ADSL are collectively
referred to as FEC, and typically convolutional Trellis Coding is combined
with Reed-Solomon block coding.

The The DSL Forum Technical Report TR-63 (addendum to TR-57) clarifies that
in general DSL management systems may specify - independently - upstream and
downstream FEC overhead between 1% and 50%.

I don't recall where MTS has it set usually, but I do recall that it's
substantial.  And on slower connections (e.g. the <1Mbps upstream
connection) adding that much overhead *can* introduce noticeable latency.
In theory, it shouldn't be double, but implementation details can alter that
assumption.

The reason FEC is used is the same reason ARQ was added to modems back in
the 2400baud days - phone lines are "noisy".  We aren't talking Cat6 cable
here, we aren't even talking Cat3, which is generally what gets run inside a
building for telephone use.  We're talking a single pair of copper wires,
often with no twist whatsoever, sometimes both in direct contact with the
ground (which does *not* provide infinite electrical resistance, i.e. it's a
partial short), sometimes with "load coils" (don't ask if you don't already
know!)... basically a worst-case scenario for data transmission.

Without FEC, so many packets would be discarded that your DSL line would be
completely useless.  Ever try to download a file when you're getting 10%
packet loss?  Try it at 90% packet loss.  Good luck :-).  So the bottom line
is, MTS errs on the side of reliability over performance.

HOWEVER: the FEC parameters are tunable on a per-modem basis, and the
upstream and downstream knobs are independent.  Does MTS implement this?  I
know they sure didn't the last time I had anything to do with their OA&M
systems (about 6 years ago).  The telco (ILEC, but not MTS) I do work with
now certainly doesn't - because management systems that can tune those knobs
intelligently and automatically are !#@$%^&* expensive, and it's just too
much work to do manually.

If Les has convinced MTS to reduce the FEC overhead, you'll get a speed
improvement of UP TO 50%, and a latency decrease of UP TO 50%.  (Anything
beyond 50% indicates non-standard implementation.)  On the other hand, if
Les didn't actually ask for that, I have to wonder if MTS is turning FEC
back down to the minimum in order to make Les' service appear less
reliable???  Considering some of the anti-competitive behaviour they exhibit
(not quite illegal, though) it wouldn't surprise me.

FWIW, previous generations of ADSL equipment typically had FEC as an on/off
switch, not a controllable parameter.  And Sean and I probably share the
same information sources inside MTS, from several years ago... And since I
don't work there anymore, and I don't know the details of their DSLAMs,
anything I've said here might be inapplicable or just plain wrong.

-Adam


-----Original Message-----
From: roundtable-bounces at muug.mb.ca [mailto:roundtable-bounces at muug.mb.ca]
On Behalf Of Dan Keizer
Sent: Tuesday, July 13, 2010 15:55
To: Continuation of Round Table discussion
Subject: Re: [RndTbl] Request confirmation...

I used to be on MTS with their DSL, but went to les.net as he provides
better options for what I would like -- and when I switched to les, my
speed doubled and my RTT went in half -- obviously MTS didn't have
things setup properly - I was even told from MTS at one point that the
loop length may have been an issue -- but, obviously it was not.  Good
thing I switched as I now have a nice full-speed DSL line :-)
I also have my VoIP hosted with les.net -- can't get better than that --

you can call .. but you can also get some information from the site
http://les.net

Dan.



More information about the Roundtable mailing list