Re: [802.3_100GCU] why transmit all parity bits after 20 data blocks in FEC frame?

[沈胜宇 <shengyushen@xxxxxxxxx>]

Dear ZhongFeng

I am sorry that I have not capture your idea.

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?

Second, 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.

Shen

On 30 September 2013 05:42, Zhongfeng Wang <zfwang@xxxxxxxxxxxx> wrote:

Hi, Shengyu,

 

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.

 

Best regards,

 

------------------------------------------

Zhongfeng Wang

Infrastucture and Networking Group

Broadcom Corp., California, USA

 

From: 沈胜宇 [mailto:shengyushen@xxxxxxxxx]
Sent: Saturday, September 28, 2013 6:54 PM
To: STDS-802-3-100GCU@xxxxxxxxxxxxxxxxx
Subject: [802.3_100GCU] why transmit all parity bits after 20 data blocks in FEC frame?

 

Dear all:

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?

Shen