how-to block ads
|
AthlGrond
Premium,MVM
join:2002-04-25
Aurora, CO
 ·Comcast
| More On FEC and Interleave I just want to add a little technical supplement to the ongoing discussions about Interleave by referencing (and blatently copying) some material about how interleave and FEC work. So here is a description and some pictures that I found for your enjoyment:
(As swiped from CommsDesign)
RS FEC
Transmission errors such as noise, interference, or distortion will occur due to problems with the signal. Once an error is detected, the most common correction scheme is to request a retransmission.
Another correction method adds some bits to the transmitted data, allowing the data to be corrected at the receiving end. This is known as FEC. One method of FEC is RS coding, which uses block codes. RS block codes are organized on the basis of groups of bits. These groups of bits are referred to as symbols. 
Symbols
Consider an example where a symbol = 6 bits and a code word = sixty-three symbols (47 payload/16 FEC). These parameters would allow the hardware on the receiving end to correct payload errors that are up to 12 bits in length.
How is a burst of noise handled? That’s where interleaving comes in. The interleaver stores symbols from different frames by row and reads them out by column.
Interleaving
So, by applying RS FEC and interleaving, the receiving unit can overcome and recover from bit errors induced by noise. While both G.DMT and G.Lite use FEC and interleaving, G.Lite uses a smaller parameter set for the FEC coding and interleaving.
--
System protected by Impregnable Ignorance (TM) | |
|  
AMD Phreak
Premium
join:2003-12-14 | Re: More On FEC and Interleave So how is the correction handled? Are the corrupted frames re-requested from the Rx end? | |
| rahvin112
join:2002-05-24
Sandy, UT
1 edit | FEC stands for Far-End Correction which implies by it's very name that the receiving end corrects the corrupted frame using the parity information stored in the frame. But I could be wrong. | |
| | 
adsldude
always learning
Premium,Ex-Mod 2003-9
join:2000-11-10
Colorado | Re: More On FEC and Interleave said by rahvin112  :
But I could be wrong.
You are right! | |
|
AthlGrond
Premium,MVM
join:2002-04-25
Aurora, CO
·Comcast
| There is a certain amount of data redundancy (the information is contained in more than one place in the transmitted data stream). So when you get a noise spike your can recover based on the redundant information.
If the redundant information is also damaged (this would be a non-recoverable error) then the data will have to be resent.
--
System protected by Impregnable Ignorance (TM) | |
| | 
Jwrviking
@qwest.net | Re: More On FEC and Interleave I have the same exact problem, i am using the actiontec 701. Someone told me to try the Cisco 678. I dont know though. Any ideas? | |
|
FEC_KING
@qwest.net
| Can you answer these questions to help me figure out why I have Near End FEC Errors accumulating at an unhealthy rate?
1 Are these errors being reported from the WAN status page at the Modem side or the DSLAM side when referenced from the customer's DSL modem?
2 Why would these errors increment at the same rate whether data is being transmitted or not? FEC adds redundant information to the data to recreate it in case it is corrupted. So in theory, if there is no data being transmitted there should be no errors, and yet my errors increment at the same rate whether I've maxed out my bandwidth or everything is idle.
3 Does the error mean that the extra bits added to the payload symbols were used to successfully re-create the the data bits, or does it mean that the entire code word had to be re-sent (Which I think should be a CRC error)
4 How can the ActionTek modem determine whether an FEC error has occurred on the DSLAM side? Does the DSLAM send back update packets for every FEC error encountered back to the ActionTek modem? If that's the case, doesn't this defeat the purpose of FEC (to fix minor errors and increase throughput by not having to re-transmit the corrupted packet)
5 Why would I be encountering millions of Near End FEC errors, but virtually zero Far End FEC errors? If the noise, interference, distortion, etc. is present, wouldn't it cause the errors to occur both places at a near 50% hit rate?
These are tough questions, so please, If you aren't sure or speculating, please say so. I can't solve my problem until I get reliable answers. | |
| |
AthlGrond
Premium,MVM
join:2002-04-25
Aurora, CO
·Comcast
| Re: More On FEC and Interleave Okay you got me, I'm not an expert, however I do think I know how this works. (So take everything through that filter.)
said by FEC_KING:
Are these errors being reported from the WAN status page at the Modem side or the DSLAM side when referenced from the customer's DSL modem?
It would be logical to assume that the near end FEC are counted by the modem, and the far end are counted by the DSLAM.
said by FEC_KING:
Why would these errors increment at the same rate whether data is being transmitted or not? FEC adds redundant information to the data to recreate it in case it is corrupted. So in theory, if there is no data being transmitted there should be no errors, and yet my errors increment at the same rate whether I've maxed out my bandwidth or everything is idle.
So long as your modem has data sync with the DSLAM you are in constant communication with the DSLAM. That communication is just as affected by the noise as is a data transmission.
said by FEC_KING:
Does the error mean that the extra bits added to the payload symbols were used to successfully re-create the the data bits, or does it mean that the entire code word had to be re-sent (Which I think should be a CRC error)
Yes, a FEC error is one that was corrected. The CRC error is one that could not be corrected and would need to be resent.
said by FEC_KING:
How can the ActionTek modem determine whether an FEC error has occurred on the DSLAM side? Does the DSLAM send back update packets for every FEC error encountered back to the ActionTek modem?
I don't know, this is the part I'm most unsure of, however if you get any indication of transmitted data FEC then the DSLAM should be reporting it. (You send data, an error occurs, and the DSLAM fixes it and reports the occurrence to you would be logical.)
said by FEC_KING:
If that's the case, doesn't this defeat the purpose of FEC (to fix minor errors and increase throughput by not having to re-transmit the corrupted packet)
Again you have a constant data stream between you and the DSLAM, I assume this kind of info is included in that data stream.
said by FEC_KING:
Why would I be encountering millions of Near End FEC errors, but virtually zero Far End FEC errors? If the noise, interference, distortion, etc. is present, wouldn't it cause the errors to occur both places at a near 50% hit rate?
The frequency space used for transmission to you from the DSLAM is different from the frequency space used to send data from you to the DSLAM. Your line can have more noise in one of those two frequency spaces. (Near end in your case.)
I hope that helps. 
--
System protected by Impregnable Ignorance (TM) | |
| packzap
join:2001-08-08
North Bend, OR
| So, I gather from the above discussion that Near End Fec errors are corrected by the modem. Therefore, don't worry about them as you would with uncorrected CRC errors.
Here's what my Actiontec GT 701 (with 5.5 firmware) shows for those errors (down/up, I guess):
Near End RS FEC (105264/0)
Far End RS FEC (312/0)
I've noticed the Near End Fec errors increase quite a bit according to the DSL speed you have with Qwest. Previously, when I was at the lower 256 kbps tier, the
near End Fec's were much lower, over time, than I now get at 1536 kbps.
I don't know how you can be assured a Cisco 678 modem will result in better permormance? | |
| | | | | |
|
