dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
20613
share rss forum feed


AthlGrond
Premium,MVM
join:2002-04-25
Aurora, CO

2 recommendations

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)

Hahausuck
Premium
join:2003-12-14
kudos:2

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
reply to AthlGrond

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
Premium,Ex-Mod 2003-9
join:2000-11-10
Colorado
kudos:1

said by rahvin112:
But I could be wrong.
You are right!


AthlGrond
Premium,MVM
join:2002-04-25
Aurora, CO
reply to AthlGrond

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)



FEC_KING

@qwest.net
reply to AthlGrond

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

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)


Jwrviking

@qwest.net
reply to AthlGrond

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?


packzap

join:2001-08-08
97000
reply to AthlGrond

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?



AthlGrond
Premium,MVM
join:2002-04-25
Aurora, CO

said by packzap:
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.
This makes sense from the standpoint of how DMT works. The more bandwidth you use the more of the frequency space will need to be used, so less reliable (for your line) frequencies will need to be used. At lower speeds the more noisy frequencies will be avoided.

(As swiped from CommsDesign again)
DMT

Dividing the available bandwidth into a set of independent, orthogonal subchannels is the key to DMT performance. By measuring the SNR of each subchannel and then assigning a number of bits based on its quality, DMT transmits data on subcarriers with good SNRs and avoids regions of the frequency spectrum that are too noisy or severely attenuated. The underlying modulation technique is based on quadrature amplitude modulation (QAM). Each subchannel is 4.3125 kHz wide and is capable of carrying up to 15 bits.
said by packzap:
I don't know how you can be assured a Cisco 678 modem will result in better permormance?
I don't know how you could be assured of that either.
--
System protected by Impregnable Ignorance (TM)