Re: [STDS-802-3-EPOC] PLC FEC presentation
Marek,
This is easy. The latency is mainly determined by the number of symbols a codeword take. The short code (48,24) would span over one and a half symbol of 20 uSec, so latency would be about 40 uSec. A long code that would span over 100 symbols, would have a latency of ~ 2 mSec.
Avi
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Thursday, March 07, 2013 4:39 PM
To: Avi Kliger; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-3-EPOC] PLC FEC presentation
Avi,
Do you have any estimates on how much of a delay FEC would cause, given that right now we would have to perform both code word and FEC word synchronization?
Marek
From: Avi Kliger [mailto:akliger@xxxxxxxxxxxx]
Sent: Thursday, 07 March, 2013 12:50 PM
To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-3-EPOC] PLC FEC presentation
Marek,
The short code proposed or even the "midsize" code are very simple to implement. I do not think that they are by any means comparable to the complexity of the data FEC and interleaver.
As I indicated on the call yesterday, the guidelines for the PLC design were higher layers requirements: minimal jitter, minimal limitations on the frequency usage, and automatic downstream signal detection by the first time connecting CNU. I believe that the proposed PLC provided these requirements with a very little complexity.
Avi
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Thursday, March 07, 2013 12:43 PM
To: Avi Kliger; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-3-EPOC] PLC FEC presentation
Avi,
Just one general comment - when we started the PLC discussions, the whole concept was focused on a low-latency, low complexity channel that requires no FEC, no interleaver and no fireworks to make it work under the worst conditions. As we go along the path, I see more and more often FEC being added to the mix. I understand we need margins to work effectively, but now we are talking about a data link channel that is becoming increasingly complex just to guarantee that we can exchange the ~1 Mbit/s worth of data. The question then becomes. Can we come up with something different, that does not require bidirectional communication prior to establishment of MAC link and skip all the inherent complexity of adding FEC into PLC?
I am concerned that at the end we will have a similar level of complexity in the PLC link as well as the main MAC link, making the whole idea of PLC just unattractive to start with. Then it is just simpler to start the whole MAC at a lower rate to begin with and forget about PLC altogether.
Marek
From: Avi Kliger [mailto:akliger@xxxxxxxxxxxx]
Sent: Thursday, 07 March, 2013 7:29 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-3-EPOC] PLC FEC presentation
Attached.
Thanks
Avi
________________________________
________________________________________________________________________
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