how-to block ads
|
FEC_KING
@qwest.net
| reply to AthlGrond
Re: More On FEC and Interleave
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
| 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) | |
|
