Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_GEPOF] Jitter clarification presentation



Hi Marek,

First of all thanks for reviewing the slides. Let me add our feedback to your observations in-line.

Thanks and best regards,
David


El 25/3/15 a las 21:24, Marek Hajduczenia escribió:
Hi David,

I must admit that stacking presentations and back referencing creates a pretty  hard to follow chain of presentations, especially if someone is trying to understand all details. Let me summarize here and see whether we can agree on the assumptions:

Observation 1: your PCS encoder (per http://www.ieee802.org/3/bv/public/Mar_2015/perezaranda_3bv_1b_0315.pdf) takes 8 bits from TX_EN lines in GMII every GTX_CLK, and stacks resulting octets one after another forming the PDB.DATA per page 4 in http://www.ieee802.org/3/bv/public/Mar_2015/perezaranda_3bv_1b_0315.pdf. What is not clear, though, is how you can assess, in advance, the TYPE information. It seems that you can only figure out whether the given PDB carries data or control after the last octet was received from GMII and you have a view of the whole frame. It would imply that TYPE needs to be located at the end of the frame. That is not clear. If I missed something obvious here, let me know, but I do not see how you can guess the type of PDB having not received the whole frame.
One obvious way would be to introduce a delay line of the size of PDB (8 octets long) and generate PDB with a fixed delay of 8 octets - this does not add jitter, but constant delay, which is acceptable and relatively small.
I completely agree with you. Indeed the functional description of the PCS Encoder shown in http://www.ieee802.org/3/bv/public/Mar_2015/perezaranda_3bv_1b_0315.pdf already shows that the encoder works in blocks, and only generates a PDB after having received a complete chunk of 8 GMII bytes. It is also the reason of having 8 GMII bytes encapsulation latency as shown in slide 12 of the same presentation. This fact is also pointed out in ieee_packet_jitter_explanation_v1.1.pdf I send yesterday in the first paragraph of slide 4 (Flow Control Block II). What you point out is exactly the reason of not doing the analysis of PCS Encoding in the presentation. As you pointed out the PCS Encoding only adds constant delay.

Observation 2:: your PCS encoder operates at the same clock rate as GMII at input, but output clock is 65/64 higher than GMII clock - that is the result of adding one bit of TYPE information to the PDB frame.
To be precise, we are not talking about clocks rates here, but about bit-rates.

Observation 3: your jitter analysis on slide 12 in http://www.ieee802.org/3/bv/public/Mar_2015/perezaranda_3bv_1b_0315.pdf makes sense to me, but not the latency analysis - that is the result of missing explanation on how TYPE field is generated. Once that is clarified, we might discuss the latency further.
On that presentation, the latency analysis of slide 12 specifies that the PCS Encoding latency is 8 GMII bytes because the PCS Encode works in blocks of 8 GMII bytes as I pointed out.

Now, moving into FEC encoder with the input rate of 65/64 * 10^9 bits, I failed to find a single demonstration of the FEC encoder bit stream and how data from PCS encoder is then chopped and mixed with FEC data. http://www.ieee802.org/3/bv/public/Jan_2015/perezaranda_3bv_1b_0115.pdf is not very helpful here - it is rich in math and theory on how it is supposed to operate, but I think to better understand the operation of FEC encoder, I need to see what the expected frame will look like after FEC encoder. The way I see is that PCS encoder will be sending data to FEC encoder either in serial fashion (one bit at a time) or in 65 bit chunks. This is not defined right now. Please clarify ...
The transmission from PCS Encoder to FEC is described as a serial stream. Presentations http://www.ieee802.org/3/bv/public/Jan_2015/perezaranda_3bv_1b_0115.pdf (slide 19) and http://www.ieee802.org/3/bv/public/Mar_2015/perezaranda_3bv_1b_0315.pdf (slide 4) completely specify the transmission order of the PDBs in the code words. The alignment between PDB and the transmitter block structure (and so to the FEC code words) can be found in http://www.ieee802.org/3/bv/public/Mar_2015/perezaranda_3bv_2c_0315.pdf, slide 4. PHD.TX.NEXT.PDB.OFFSET provides the necessary alignment between the PDB and the transmitter block structure.
And finally, onto the presentation you attached. While I can agree that the PCS encoder does not add packet level jitter (it might add systematic delay - to be clarified per discussion above), I do not agree with the statement that per [1] there is no packet jitter. PCS encoder is not the only source of jitter in the stack. FEC encoder is another and that one is poorly defined right now.

I do not follow the need for flow control block on slide 3 - the way you defined PCS encoder in  http://www.ieee802.org/3/bv/public/Mar_2015/perezaranda_3bv_1b_0315.pdf, there is no need for any flow control of any kind - you have 64/64 bit rate in, and 65/64 bit rate out and unless you are trying to clock both sides at the very same rate, there are no problems. I believe all designs I have seen so far assume that output from PCS encoder is not serial but rather block oriented, which takes away some of clock alignment problems (and adds other problems), but at least avoids the need for fancy flow control functions of any kind. Data is collected in 8-bit chunks at GMII clock rate, processed and then delivered to FEC encoder in 65 bit chunks every 8 GMII clock cycles.

Since there is no clarify on some items in PCS encoder and FEC encoder structure, I cannot really assess whether the analysis you show is correct or not. Furthermore, state diagrams would really help here - paper analysis is fun, but we need to get down to details and these will be hard to come by until we see state diagrams to examine and punch holes in.
In this case I'm sorry to say that I do not agree with you. Indeed the core of the presentation I sent yesterday analyses not the PCS Encoder (this subject is addressed in a single paragraph of a 13 page presentation), but the rest of the system. As pointed out in slide 12 of ieee_packet_jitter_explanation_v1.1.pdf, any system implementing any kind of block codes will have rate fluctuations due to the insertion of the redundancy information. The rate also fluctuates when other extra information is inserted. As pointed out in the presentation for 1000BASE-RH this happens in the FEC (on L1 the BCH encoder adds redundancy), and also when PHD/S1/S2 information is inserted in the transmitter block structure. As the presentation indicates, this fact is not specific of 1000BASE-RH, and to exemplify this two other systems have been shown for comparison. In my opinion the analysis shown in ieee_packet_jitter_explanation_v1.1.pdf is complete, as it address all the possible source of jitter in the system (specifically it address the effect of the FEC in the jitter that you mention), and shows that the solution to avoid any jitter problem (already presented and adopted in http://www.ieee802.org/3/bv/public/Mar_2015/perezaranda_3bv_1b_0315.pdf and http://www.ieee802.org/3/bv/public/Jan_2015/perezaranda_3bv_1b_0115.pdf is a rate adaptation block that makes the PCS Encoder block work with a true, fixed, constant bit rate (so no rate fluctuations whatsoever). I'm also confident that you will see how everything fits perfectly when you see the standard document draft with all the relevant state diagram and associated descriptions.


Thanks for the presentation

Marek Hajduczenia, PhD
Network Architect, Principal Engineer
Bright House Networks
Office +1-813-295-5644
Cell +1-813-465-0669

-----Original Message-----
From: David Ortiz [mailto:david.ortiz@xxxxxxxxx]
Sent: Wednesday, March 25, 2015 11:22 AM
To: STDS-802-3-GEPOF@xxxxxxxxxxxxxxxxx
Subject: [802.3_GEPOF] Jitter clarification presentation

Dear all,

We have prepared a small presentation to clarify the doubts that were raised during the last plenary meeting regarding the packet jitter in 1000BASE-RH.
Please find it attached to this email.

We will be happy to answer any question/doubt that might arise.

Best regards,
David

--
Knowledge Development for POF SL
Ronda de Poniente 16, 2ºA
28760 TRES CANTOS (Madrid) - Spain
www.kdpof.com
email: david.ortiz@xxxxxxxxx


--
Knowledge Development for POF SL
Ronda de Poniente 16, 2ºA
28760 TRES CANTOS (Madrid) - Spain
www.kdpof.com
email: david.ortiz@xxxxxxxxx
Tfn: +34-918043387, +34-918062035 - Fx: +34-918063725