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> 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]
> *Sent:* Wednesday, January 29, 2014 10:05 AM
> *To:* 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> 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> 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> 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 <laubach@xxxxxxxxxxxx>
> *Sent:* Monday, January 27, 2014 4:19 PM
> *To:* 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
>
> 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
>
>
>
>
> ------------------------------
>
>
> ------------------------------
>
>
>
>
> ------------------------------
>
>
>
>
> ------------------------------
>
> <="" 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