FEC Summary. Ed Boyd, Xingtera. IEEE 802.3bn January

Size: px

Start display at page:

Download "FEC Summary. Ed Boyd, Xingtera. IEEE 802.3bn January"

Kenneth Riley
5 years ago
Views:

1 FE Summary Ed Boyd, Xingtera IEEE 802.3bn January

2 FE Summary Encoder Delay Decoder Delay Overall omplexity Efficiency* Medium Only 0 Med 80.4% Easy Long Short Long Long 87.4% Medium Long Short 0 Long 87.4% Medium arity at End Long Med Long Long 87.4% Difficult Short L M S 0 Long 87.4% Difficult arity at End L M S+ K/2 Long + Short/2 Long + Short/2 87.4% Most Difficult *128 Users at 1Gbps upstream IEEE 802.3bn January

3 alculating FE Overhead The LT must calculate the burst size from the REORT value. 64/66 Overhead Vectors_Bits = 160*65/64*REORT_Value FE Overhead Medium Only _FE_Bits = Vector_Bits + ROUNDU(Vector_Bits/4940)*(900+40) Simple Single Divider L S _FE_Bits = Vector_Bits + INT(Vector_Bits/14300)*( ) + ROUNDU(REMAINDER(Vector_Bits/14300)/800)*(280+40) Requires 2 Dividers L M S TAIL_BITS = TABLE_LOOKU(REMAINDER(Vector_Bits/14300) _FE_Bits = Vector_Bits + INT(Vector_Bits/14300)*( ) + TAIL_BITS Requires a Divider and a Table Lookup IEEE 802.3bn January

4 FE Summary K/2 IEEE 802.3bn January

5 LT K/2 SNR Advantage? Without K/2 Full Full Full Short NU LT Full SNR Full SNR Full SNR Great SNR With K/2 Full Full Med Med NU Full SNR Full SNR Better SNR Better SNR Without K/2, Final Short codeword has much better SNR than Full blocks. With K/2, last 2 blocks have better SNR. Overall SNR is still limited by Full Block size SNR since improvement only on last block on certain block sizes. K/2 Does not improve overall SNR IEEE 802.3bn January

6 K/2 Decode Delay Start Decode Start Decode Start Decode Start Decode LT Full Full Full Short NU Without K/2 Start Decode Start Decode Start Decode LT Full Full Med Med NU With K/2 Without K/2, decoding starts after full codeword of data or End of burst marker. With K/2, decoding is delayed until half of next codeword or end of burst marker. With K/2, decoding the final 2 blocks starts at last code word. K/2 Increases Decoder Delay IEEE 802.3bn January

7 K/2 Encode Delay Add arity at End Add arity at End Add arity at End Add arity at End ass ass ass ass LT Full Full Full Short Without K/2 NU Delay until mid block To pass data Delay until mid block To pass data Delay until mid block To pass data When End of burst, alculate parity to Mid point and insert In data stream LT Full Full Med Med With K/2 NU Without K/2, transmit data is not delayed and parity is always after data. With K/2, transmitter must delay data until mid point of next block to determine where parity will be inserted. With K/2, parity calculation can t start until end of burst for last 2 blocks and must be inserted in non end location. K/2 Increases Encoder Delay and omplexity IEEE 802.3bn January

8 FE Summary 65 BIT VETOR ALIGNMENT IEEE 802.3bn January

9 ayload Alignment R 40 ARITY In the Eo downstream, the FE payload carries an even multiple of 65 bit vectors. Allows FE alignment to set vector alignment. Should the Eo upstream use payload sizes aligned to the 65 bit vectors? Alignment makes it easier to discard a bad FE block. Alignment Efficiency enalty Short Efficiency: 70.9% vs 71.4% (75% without R 40) Med Efficiency: 84% vs 84.2% (84.8% without R 40) Long Efficiency: 88.6% vs 88.6% (88.9% without R 40) IEEE 802.3bn January

10 Final FE Block of Burst IDLE Filler R 40 ARITY Resource BlkBoundaries Bursts will not naturally end at Resource Block Boundaries (RBB) so idles must added to the end of the burst. Adding data after the parity would not allow end marker to identify the FE size. IDLE characters must be inserted before the R 40 and arity. (The required data may change the type or amount of FE parity). The IDLE filler inserted to reach the RBB may cause the FE parity to increase or an additional FE block added. We should NOT require the final FE block payload to be a multiple of 65 bit vectors so the FE ends at the RBB. (No alignment issue at end of burst) IEEE 802.3bn January

11 Start of Burst Vector Alignment onclusion Full ode Word Full ode Word Full ode Word Short ode Word(s) Even multiples of 65 bits in each payload No Vector Alignment Required Alignment of vectors for full size Long code words has a minor (<.1%) impact on efficiency. It is easier to discard FE code words and realign with the vector of the next FE block if payload is multiples of 65 bits. No added complexity since it is the size definition from downstream. The End of burst FE Block(s) will not require vector alignment so the FE can align with end of the Resource Block. There is no benefit for realignment at the end of the burst and the alignment penalty is higher on short code words. Vector Alignment on Start/Middle ode Words IEEE 802.3bn January

12 FE Summary LONG MEDIUM SHORT IEEE 802.3bn January

13 Multiple ode Word omplexity Medium Only [Transmitter] LT Med Med Med R 40 R 40 R 40 NU ass while alc R 40 & alc FE Long Medium Short Add R 40 And arity Add parity at End of Burst Buffer to Determine FE and insert R40/arity LT Long Med Short Short R 40 R 40 R 40 R 40 NU Example : Insert 3 parities at End of Burst End of FE blocks. Medium only has no transmit buffering delay and parity only inserted at the end. LMS requires that transmitter buffer data so it can insert the parity/r 40 between multiple different size blocks of data. K/2 not considered. IEEE 802.3bn January

14 arity at the End Long Medium Short No Delay Buffer Required LT Long Med Short Short NU Insert 3 parities at End of Burst If parity for 1 or more blocks is always transmitted at the end, transmit data doesn t need to be delayed. Multiple Sized Encoders need to calculate parity on multiple data block sizes at the end of the burst. K/2 not considered in this slide. IEEE 802.3bn January

15 Single R40 at the End Long Medium Short LT Long Med Short Short Long Medium Short R 40 R 40 R 40 R 40 NU LT Long Med Short Short R 40 R 40 NU Single R40 for all parity blocks Inserting R 40 at the end of the code words would require transmit buffering and the shifting of data. The end of burst is less data than a full long code word so a single R 40 would be simpler and more efficient. IEEE 802.3bn January

16 Multiple ode words (L M S) [@End] Assume arity at the end and a single R 40 for a long code word or end of burst blocks The tail of a burst can use 1 or more smaller code words to shorten the parity required. The code word sizes can be determined by the number of bits in the block. ode word alignment is not required on the end of the burst. The Look up table below shows the most efficient code words sizes and required parity for any block size. Min Bits Max Bits BitsLong Long Medium Medium Short Short R40 arity R40 Bits Overhead arity Bits bits bits bits bits bits bits bits bits IEEE 802.3bn January

17 Multiple ode words (L M S) Same sent out regardless of size of block. Single R 40 and block of parity avoids variable delay buffer and complexity. IEEE 802.3bn January

18 Multiple ode words (L M S) The tail of a burst can use 1 or more smaller code words to shorten the parity required. The code word sizes can be determined by the number of bits in the block. ode word alignment is not required on the end of the burst. The Look up table below shows the most efficient code words sizes and required parity for any block size. Min Bits Max Bits Long Medium Short R40 arity Bits R+arity bits bits bits bits bits bits IEEE 802.3bn January

19 Multiple ode words (L M S) LT NU bits: 1 Short bits: 2 Short bits: 1 Medium + 1 Short bits: 1 Medium bits: 1 Medium + 1 Short bits: 1 Medium + 1 Short bits: 1 Long Must stop transmitting and buffer Since I may or may not need to insert R and FE parity. Stop at 800 bits of 14K bit block. After end of burst, parity and R 40 must be alculated and inserted earlier in data stream. Buffering and insertion delay is variable. To avoid delay of recalculating, multiple R 40 calculators and encoders could be used IEEE 802.3bn January

20 FE Summary LONG SHORT IEEE 802.3bn January

21 Long Short (all at end) Long Short N x Short Blocks N x Short arities LT Long Short Short Short Short R 40 R 40 NU Single R40 for all parity blocks Transmitter running 2 encoders (short and long) would have no additional delay or jitter. If R 40 is bad, all end of burst blocks are lost. (Still Less lost than bad Long block) IEEE 802.3bn January

22 Multiple ode words (L S) [All at End] LT NU 1xShort Block 2xShort Block 3xShort Block 4xShort Block 5xShort Block 6xShort Block Must stop transmitting and buffer Since I may or may not need to insert R and FE parity. IEEE 802.3bn January

23 Multiple ode words (L S) LT NU Same sent out regardless of size of block. Single R 40 and block of parity avoids variable delay buffer and complexity. FE size increases simply with block size. IEEE 802.3bn January

24 Multiple ode words (L S) If the Medium code word size is not used, the following look up table could be used to select the parity. ode word alignment is not required at the end of burst. Assumes arity at the End with Single R 40. Min Bits Max Bits Long Short R40 arity Bits IEEE 802.3bn January

25 FE Summary IMAT OF FE/ARITY AT END IEEE 802.3bn January

26 arity/r 40 at End ROs arity/r 40 at End is more efficient. arity/r 40 at End has lower delay on transmitter. arity/r 40 at End simplifies transmitter. (To be explained) oncerns Raised on all arity/r 40 at End lowers the ability to detect errors. Will show that it isn t an issue. arity/r 40 increases delay on receiver. Will show that it isn t an issue. If arity/r 40 at End is less complex, lower delay, and more efficient, we should use it. IEEE 802.3bn January

27 Multiple ode words (L M S) [@End] Assume arity at the end and a single R 40 for a long code word or end of burst blocks The tail of a burst can use 1 or more smaller code words to shorten the parity required. The code word sizes can be determined by the number of bits in the block. ode word alignment is not required on the end of the burst. The Look up table below shows the most efficient code words sizes and required parity for any block size. Min Bits Max Bits Long Medium Short R40 arity Bits Min Bits Max Bits Long Medium Short R40 arity Bits R40 + arity bits bits bits bits bits bits bits bits IEEE 802.3bn January

28 Multiple ode words (L M S) [@End] LT NU bits: 1 Short bits: 2 Short bits: 3 Short bits: 1 Medium bits: 1 Medium, 1 Short bits: 1 Medium, 2 Short bits: 1 Medium, 3 Short 7520 bits: Long IEEE 802.3bn January

29 Multiple ode words (L M S) The tail of a burst can use 1 or more smaller code words to shorten the parity required. The code word sizes can be determined by the number of bits in the block. ode word alignment is not required on the end of the burst. The Look up table below shows the most efficient code words sizes and required parity for any block size. The multiple R 40 s make 2 of the sizes more inefficient than a single block. Min Bits Max Bits Long Medium Short R40 arity Bits R+arity bits bits bits bits bits bits bits bits IEEE 802.3bn January

30 Multiple ode words (L M S) The tail of a burst can use 1 or more smaller code words to shorten the parity required. The code word sizes can be determined by the number of bits in the block. ode word alignment is not required on the end of the burst. The Look up table below shows the most efficient code words sizes and required parity for any block size. Min Bits Max Bits Long Medium Short R40 arity Bits R+arity bits bits bits bits bits bits IEEE 802.3bn January

31 Multiple ode words (L M S) LT NU bits: 1 Short bits: 2 Short bits: 1 Medium bits: 1 Medium + 1 Short bits: 1 Medium + 2 Short bits: 1 Long Must stop transmitting and buffer Since I may or may not need to insert R and FE parity. Stop at 800 bits of 14K bit block. After end of burst, parity and R 40 must be alculated and inserted earlier in data stream. Buffering and insertion delay is variable. To avoid delay of recalculating, multiple R 40 calculators and encoders could be used IEEE 802.3bn January

32 S Transmit Buffer Slots to other NUs Gearbox FE Encoder + R40 Burst 1 Burst 2 Burst n Fixed Delay Buffer Detector acket Buffer IDLE Deletion XGMII (Required if parity isn t at end) If arity/r40 is not at the end, a fixed delay transmit buffer is required in the S. [Shown between Detector and FE Encoder] The buffer allows the FE encoder to know the end of burst tail size and place R 40 and parity. Size of the Buffer The delay will need to be 6,600 bits at the lowest data rate. 6, Mbps = 26.4us (Max Delay at low speed) 1Gbps = 26,400 bits (Max Size at high speed) # of Bursts in the buffer Bursts can be 1 to 1.5 us for polling or single packet. Buffer may contain 1 burst or up to 20+ bursts. Buffer adds complexity and adds delay; we should avoid it. IEEE 802.3bn January

33 R 40 overage A single R 40 does not decrease the R 40 error detectability. SNR is about the same for all code word sizes Short (28.8db), Medium (29.1db), Long (29.7db) From Broadcom Victoria resentation. R 40 overage R 40 covers 14K bits on long code words. R 40 covers 5K bits for LS or 6.6K LMS for the longest multiple FE end of burst. R 40 still covers the age of the universe IEEE 802.3bn January

34 FE Receiver Delay 1) Received 2) Start Decode 1) Received 2) Start Decode? Short End of bursts have extra time to decode. LT Long Long Short Short Long NU Decoder Busy Decoder Busy Decoder Busy FE Decoder Delay 3) Released Delay through FE Decoding (S) must be a constant. FE Decoding Delay must be the same for all data. Longest Delay is Full Size Block Long Block. (Shown above). Required FE Decoder Delay 3) Decoding Finishes early There is no advantage to decoding the end of burst and certain end of burst sizes faster. (data must be buffered to match HY delay anyway). All 3 possible positions for decoding start (Green #2) will have data available early. 4) is buffered to fixed delay. IEEE 802.3bn January

35 FE Receiver Delay (2) LT NU bits: 1 Short Exactly the same for R 40/arity at End bits: 2 Short bits: 1 Medium bits: 1 Medium + 1 Short bits: 1 Medium + 2 Short bits: 1 Long 1 Short, 1 Medium, and 1 Long will start decoding at the end of the burst with or without R 40/arity at the end of burst. Starting a few of the middle burst endings early doesn t provide a fixed delay improvement. Heavy ost: Decoder isn t ready until end of burst anyway. 3 times decoder speed up is required to start decoding early. No Value: A variable delay on the end of burst doesn t change the fixed HY delay. Early Decoding is more complexity for no value IEEE 802.3bn January

36 FE Receiver Throughput arity & R 40 per block arity & R 40 at End The placement of the parity does not change the FE decoding throughput. The amount of time to decode the multiple short and/or medium blocks is the same for both cases. Starting earlier doesn t increase the throughput. IEEE 802.3bn January

37 Back to Back Short Burts 1) Received 2) Start Decode LT Min Gap Long Long Short Short NU Decoder Busy Decoder Busy Decoder Busy Decoder Busy (short End) Decoder Busy (short start) Min Gap between bursts is determined by FE decoding rate. (it is not a function of the last blocks delay). Base Equations LongBlockTime >= LongDecodeTime 2xShortBurstTime + MinGap >= 2xShortDecodeTime LongBlockTime + ShortEndTime + ShortBurstTime >= LongDecodeTime + ShortEndDecodeTime + MinGap + ShortDecodeTime IEEE 802.3bn January

38 arity & R 40 per block arity & R 40 at End Summary arity & R40 at End has no decoder disadvantages Decoding starts at the end of the burst for both methods. Too expensive to start early on short blocks. Even if started early, there is no change to HY delay or FE throughput. arity & R40 at End has advantages and no disadvantages It is more efficient. Lower Transmitter Delay Significantly reduces transmitter complexity Single R40 generator. No transmitter delay buffer to find end of bursts. All S blocks [Idle Deletion, Detector, FE Encoding, Gearbox] are working on the same burst in time. IEEE 802.3bn January

39 FE Summary BURST ERFORMANE IEEE 802.3bn January

40 EON 10G vs Eo Medium R 40 and FE arity added for both cases. 0.7 Eo Medium ode Word only is generally more efficient than 10G EON FE FE Efficiency G Full ode Word Eo Medium Shortened Does Eo needs to improve efficiency over 10G EON? How can we compare these graphs and get the overall system efficiency? Burst Size (Bytes) IEEE 802.3bn January

41 Eo Medium vs Eo LS Eo with a mixture of Long and Short code words improves performance on short and long bursts. FE Efficiency Eo Med Eo LS Efficiency = Vector ayload/(vector ayload + R40 + arity) Is it enough to justify complexity? Burst Size (Bytes) IEEE 802.3bn January

42 Eo LS vs Eo LMS Eo with Long, Medium, and Short ode words increases the efficiency of burst sizes in the range of 400 Bytes to780 Bytes. FE Efficiency Eo LMS Eo LS Bursts will normally be smaller than 400 Bytes for AKs, polling, etcs. Bursts on a loaded system will be larger than 780 Bytes Overall, Little or no performance improvement for LMS over LS. Burst Size (Bytes) IEEE 802.3bn January

43 FE Summary SYSTEM EFFIIENY IEEE 802.3bn January

44 Burst vs System Efficiency Burst Efficiency does not give a realistic worst case system efficiency. It is impossible to only have small bursts. If all NUs are transmitting small bursts and aren t getting enough bandwidth, they will start sending large bursts. It is impossible to only have large bursts. Some NUs will only have AKs or polling to send. Worst ase System Efficiency Upstream rate and number of NUs are inputs. Assume that all NUs except 1 are transmitting the smallest least efficient burst. One NU is transmitting a large burst to fill in the rest of the data in a 2ms cycle time. IEEE 802.3bn January

45 System Efficiency 250Mbps 250Mbps 500Mbps 500Mbps 1Gbps 1Gbps Medium 76.6% 68.4% 80.5% 76.5% 82.3% 80.4% LS 86.1% 83.7% 87.4% 86.2% 88% 87.4% LMS 86.1% 83.7% 87.4% 86.2% 88% 87.4% Medium is around 9% less efficient than Long & Short. ~9% 250Mbps, ~9%@500Mbps, ~5 7%@1Gbps Is it worth the additional complexity? LMS has no advantage over LS Small and Long bursts set efficiency Byte burst advantage for LMS doesn t show up. No need for LMS. IEEE 802.3bn January

46 FE Summary ONLUSIONS IEEE 802.3bn January

47 onclusions Medium ode Word only is the simplest solution Efficiency is close to 10G EON FE Long & Short improves efficiency 5% to 15% system efficiency improvement arity should be at end to avoid transmit delay/jitter. Single R40 should be at the end of burst block Is it worth the complexity added? Long & Medium & Short erformance improvement is not worth complexity added over LS. K/2 Adds delay and complexity with no clear benefit for Eo Alignment to 65 bit vectors Start/Middle of burst blocks should have payload aligned to 65 bit vectors. End of burst blocks should not be aligned. FE arities should not be padded to align to 65 bit vectors. IEEE 802.3bn January

48 Straw oll #1 Do you think that we should include K/2 for the last code word block? Yes: No: IEEE 802.3bn January

49 Straw oll #2 Which FE method do you prefer? Medium Only: Long & Short: Long, Medium, & Short: Other: Undecided: IEEE 802.3bn January

50 Straw oll #3 Assuming L S or L M S, how should we handle the R 40 s and arity bits in the end of burst code word blocks? R 40 in every block and parity in each block: R 40 in every block and all parity at end: Single R 40 and all parity at end: Other: Undecided: IEEE 802.3bn January

51 Straw oll #4 What should be kept as multiples of 65 bit vectors? All FE payloads and FE parities: All FE payloads: Full Length Long FE payloads: None: Undecided: IEEE 802.3bn January

52 FE Summary BAK U IEEE 802.3bn January

53 Multiple ode words (L M S) LT NU bits: 1 Short bits: 2 Short 1641 bits: 2 Short Must stop transmitting and buffer Since I may or may not need to insert R and FE parity. Stop at 800 bits of 14K bit block. After end of burst, parity and R 40 must be alculated and inserted earlier in data stream. Buffering and insertion delay is variable. To avoid delay of recalculating, multiple R 40 calculators and encoders could be used. IEEE 802.3bn January

Multiple Profiles for EPoC. Andrea Garavaglia and Nicola Varanese - Qualcomm IEEE 802.3bn Task Force Interim Phoenix, AZ

Multiple Profiles for EPoC. Andrea Garavaglia and Nicola Varanese - Qualcomm IEEE 802.3bn Task Force Interim Phoenix, AZ Multiple Profiles for EPoC Andrea Garavaglia and Nicola Varanese - Qualcomm IEEE 802.3bn Task Force Interim Phoenix, AZ Supported by Jorge Salinger (Comcast) IEEE 802.3bn Phoenix, AZ 2 Multiple Profile