D the interleaver depth is set to 1 both up and down on his line - that's fast path
so there is no error correction routines on the line so no FEC's
EDIT:
You're right -
les70 does seem to have FEC disabled - you set me thinking about this though..
So far as I know, Forward Error Correction is independent of the interleaving depth. Reed-Solomon-FEC of the frame payload can still be used with Fast Path. Interleaving simply spreads the codewords across several frames to relieve the load on the RS decoder. But those interleaved codewords need not actually have any redundancy bytes added for forward error correction.
So just as Fast Path can use FEC, there can also be an interleaved latency path with no FEC. The Forward Error Correction function and the latency path are configured independently. [1] [2]
It seems that some modems maintain separate FEC counters for Fast Path and for interleaved latency paths, e.g see this DSL modem from
US Robotics which has counters specifically for Fast Path FEC Correction. [3]
Back in December,
Kitz contributor
JustAnother, went to a lot of trouble identifying all of the cryptic field names reported by the xdslcmd tool. [4]
JustAnother found a
Comtrend manual hosted by
Andrews & Arnold which lists the following: [5]
Looking back at
les70's stats, his modem lists the interleaving depth as 0 (zero) and the number of RS Codeword check bytes as 0 (zero). So unless that is wrong, it does look like RS-FEC is disabled altogether.
By contrast, this from my modem:
According to [2], in my case, the RS decoder takes M data frames, each of B octets (bytes). M*B is the size of the FEC data frame = (2*123) = 246 octets. That becomes the size of the Reed-Solomon codeword. The number of redundant check bytes in the RS codeword is given by R, which in this case is 6. So this FEC configuration (n,k) = RS(246,240). Since RS can correct (n-k)/2 symbols in error per codeword, if a symbol is taken to be a octet, this means that up to 3 octets per 246 octet codeword can be corrected by the RS decoder. However, thanks to the spreading from that huge interleaving depth D=64, the decoder could still correct a codeword where many more than 3 octets are in error.
Does that sound about right?!
cheers, a
[1]
https://eeweb01.ee.kth.se/upload/publications/reports/2008/XR-EE-KT_2008_003.pdf (see 1.4.2)
[2]
http://huaweihg612hacking.files.wordpress.com/2012/06/80107515-g992-3-minusannexc-2009-04-final.pdf (see 7.7.1.4)
[3]
http://www.usr.com/support/9111/9111-ug/adsl-2.htm[4]
http://forum.kitz.co.uk/index.php/topic,10289.0.html[5]
http://wiki.aaisp.org.uk/images/d/dd/UM_AR-5382u_A1.0.pdf
