|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
ShenSecond, if the answer to 1 is yes, then why not trasmite the encoded 514 bits and 14 bits parity together, such that the receiver can decode it into 514 bit immediatelly? instead, gustlin transmite the 514 first, followed by another 9 514 bits, and then the 14 parity bits of the first 514 data.First, is the RS(528,514) schema presented in http://www.ieee802.org/3/bj/public/mar12/gustlin_01_0312.pdf page 10 the final fec used in 802.3bj draft?Dear ZhongFengI am sorry that I have not capture your idea.
On 30 September 2013 05:42, Zhongfeng Wang <zfwang@xxxxxxxxxxxx> wrote:
RS code is a symbol-based block error correction code.
Major encoding and decoding operations are performed on “symbols”.
In our case, a symbol has 10 binary bits. So a FEC frame has exactly one RS block.
Hope this helps.
Infrastucture and Networking Group
Broadcom Corp., California, USA
From: 沈胜宇 [mailto:shengyushen@xxxxxxxxx]
Sent: Saturday, September 28, 2013 6:54 PM
Subject: [802.3_100GCU] why transmit all parity bits after 20 data blocks in FEC frame?
in http://www.ieee802.org/3/bj/public/mar12/gustlin_01_0312.pdf page 10, the fec frame contains 10 Reed solomon encoded blocks. each blocks contains 514 original data bit and 14 parity bits.
But all these 14*10 parity bits are transmited after all 514*10 data bits. I think this leads to large latency in fec decoding, because decoding the first 514 bits can not happen before its 14 parity bits arrived.
So why not transimit 14 parity bits with their corresponding 514 original data bits?