Re: [STDS-802-3-EPOC] Any presentations for Wednesday's scheduled PHY Sub-Group Conference Call?
Marek,
As you note, there exist disparate arguments on this topic, some of which are unsubstantiated. I believe that removing the hand-waving unsubstantiated points (“opinions”) with facts will be educational and resolve the need for “believing”.
Rich
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Wednesday, January 29, 2014 10:46 AM
To: Rich Prodan
Cc: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Any presentations for Wednesday's scheduled PHY Sub-Group Conference Call?
Rich,
I do not believe anybody argues against the use of LDPC codes, so we can put that avenue to rest. What I am arguing is that I hear contradictory arguments being made, and not being able to test each and every possibility myself, I have a hard time believing either side of the argument: one says it is black, another one says it is white. It is very hard to build an educated opinion on this topic where such disparate opinions are voiced. The logical solution would be for all people who understand FEC to get together and work out differences and present a single agreed proposal. Otherwise, it is hard to expect that all TF members become experts in this area overnight and be able to argue one way or another.
Marek
On 29 January 2014 12:30, Rich Prodan <rprodan@xxxxxxxxxxxx<mailto:rprodan@xxxxxxxxxxxx>> wrote:
All-
If simple algebra is too complicated for your understanding of optimizing efficiency, then perhaps understanding these simple algebraic relationships for multiple codeword sizes and their respective thresholds that minimize the total number of parity bits in a burst is the key. It is not rocket science, nor even information theory and belief propagation, which the latter is required to understand the utility of LDPC codes (which I assume nobody wants to replace with RS or BCH block codes which are much simpler but less efficient algebraic codes).
Furthermore, the hardware to decode multiple sizes of the current upstream quasi-cyclic LDPC codes is about the same as the single longest such LDPC code.
Additional encoding/decoding delay is similarly negligibly different unless we place the coded bitstream directly on the transmission medium like EPON. EPoC requires a 1D to 2D mapping of the entire coded bitstream in the burst onto OFDMA resource blocks (or all resource blocks if allocated the entire symbol for a long burst). Only then can the inverse FFT be performed and the resulting waveform be transmitted in the appropriate frequency band.
I believe that this understanding can be achieved so that 7% to 15% of efficiency is not wasted for NO substantial decrease in cost or hardware complexity.
Rich
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx<mailto:marek.hajduczenia@xxxxxxxxx>]
Sent: Wednesday, January 29, 2014 10:05 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] Any presentations for Wednesday's scheduled PHY Sub-Group Conference Call?
I would rather to work off a simple scenario and try to figure out whether it is acceptable, rather than try to simplify something unnecessarily complex
Just an opinion, nothing more. And as always, I believe my take on your presentation after it is given live will be different than when I read it myself ;)
Marek
On 29 January 2014 11:50, Ed Boyd <ed_boyd@xxxxxxxxx<mailto:ed_boyd@xxxxxxxxx>> wrote:
Marek,
I agree that it is far too complicated. I want to remove some of the complications. I compared the simplest method of a single medium shortened to what has been approved so far. At a minimum, we can remove complexity that has negative or little performance improvement. Of course, we could decide to go with the simplest approach. I'm trying to clearly identify the difference on each option.
Thanks
Ed
Sent from my iPad
On Jan 29, 2014, at 7:12 AM, Marek Hajduczenia <marek.hajduczenia@xxxxxxxxx<mailto:marek.hajduczenia@xxxxxxxxx>> wrote:
Ed,
In all honesty, I look at your presentation and I am getting really lost in all options and conclusions being drawn. Is it just me, or we are just overdoing it on the side of options and optimizations? What's wrong with picking just medium FEC codeword and allowing for codeword truncation at the end? The decoding process should be fairly easy, since it would be driven by either full FEC codeword or end of burst marker sequence. It does not seem to affect negatively SNR and decoder latency and at the same time we avoid all the complexity of options, filling algorithms and assumptions that the CLT has to make to calculate the size of the grant to accommodate reported data.
I feel that we are driven to decide based only on the very noble, but yet completely impractical notion of very high efficiency. Ethernet has been always about low cost and robustness and not perfect efficiency. I understand the need to use the spectrum resource efficiently, but after a certain efficiency point, cramming more bits into the channel incrementally increases the overall system cost, its complexity and decreases its robustness.
My suggestion is therefore simple: pick medium FEC codeword we have defined right now, allow for codeword truncation and move on.
Regards
Marek
On 28 January 2014 17:51, Ed Boyd <ed_boyd@xxxxxxxxx<mailto:ed_boyd@xxxxxxxxx>> wrote:
Hi Mark,
I would like to discuss the attached presentation and get feedback tomorrow if possible. I tried to expand on the comments from the FEC filling algorithm discussion at the meeting.
Thanks,
Ed…
Sent from Windows Mail
From: Mark Laubach<mailto:laubach@xxxxxxxxxxxx>
Sent: Monday, January 27, 2014 4:19 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Dear IEEE P802.3bn Task Force Participants,
Our scheduled PHY sub-group conference call is this Wednesday at 10AM Pacific.
If you have any presentations for socialization or other topics, please send them on the reflector by 5PM Pacific tomorrow (Tuesday).
Please be familiar with the IEEE SA Patent Policies at:
https://development.standards.ieee.org/myproject/Public/mytools/mob/slideset.pdf
WebEx Meeting Number: 920 271 005<tel:920%20271%20005>
To start: https://broadcom.webex.com/broadcom/j.php?J=920271005
Yours truly,
Mark Laubach, Chair
IEEE P802.3bn EPoC PHY Task Force
Broadband Communications Group
Broadcom Corporation
1351 Redwood Way
Petaluma, CA, 94954
<image001.jpg>
Tel: +1.707.792.9093
Cell: +1.650.996.2219<tel:%2B1.650.996.2219>
________________________________
________________________________
________________________________
________________________________
<="" p="">
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1