| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi David Inline with [mh0326] in green, please Marek -----Original Message----- 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. [mh0326] OK, we’re on the same page then – we have a constant 8 octet delay within PCS encoder in transmit direction to be able to figure out TYPE value – my confusion and uncertainty came from page 7 in http://www.ieee802.org/3/bv/public/Mar_2015/perezaranda_3bv_1b_0315.pdf, where you show no timing delay between GMII and PDB created, which kind of implied to me that there is no delay within PCS encoder. A drawing similar to Figure 65–5 would be very helpful in understanding temporal and delay relationship between bottom of GMII and output of PCS encoder. Just a thought for the draft going forward. > > 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. [mh0326] As far as I am concerned, these are complimentary. Either way, we’re on the same page here – bit rates in and out of the PCS encoder are in 65/64 ratio. > > 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. [mh0326] I fear these specify the transmission order off PCS encoder (slide 4) but slide 19 is a bit cryptic. What I am after is a drawing similar to Figure 76–13, which shows code word, bit, etc flow and how things are aggregated into different transmit patterns. At this time, I do not have enough information to be able to draw something like this for this new PHY and this helps examine any choke points and jitter / latency analysis for the proposed stack. 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. [mh0326] It is OK to disagree J I did not have the benefit of attending each and every meeting of this group, so I am trying to understand what was agreed based on baselined proposals and build a picture of a working system. I failed. Perhaps the draft (once available) will lift some of the fog and help me understand what was really baselined. I am concerned, though, is that a lot of details were accepted without looking into state diagrams and their interaction, but I guess we will have time to examine it in more detail when the first draft for TF review becomes available. Until then, I cannot really comment on whether your analysis is valid or not. > > 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 > email: david.ortiz@xxxxxxxxx > -- Knowledge Development for POF SL Ronda de Poniente 16, 2ºA 28760 TRES CANTOS (Madrid) - Spain email: david.ortiz@xxxxxxxxx Tfn: +34-918043387, +34-918062035 - Fx: +34-918063725 |