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