| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Steve, That is probably a very good point and should be covered in the CFI deck, since these issues are the core of what needs to be fixed. As the last deck was presented, it seems to have the priorities inverted – a lot of focus on the market for PTP (I think we know where it is needed by now) but the gist of what the actual ask is seems to be hidden in the annexes. A lower level (more of crayon-style) explanation of the problems would be really handy because it does take a lot of know-how to figure out what the actual factors impacting the precision are. I will be more than happy to put some time into the deck work if that is what it takes Marek From: Trowbridge, Steve (Nokia - US) <steve.trowbridge@xxxxxxxxx> Hi Marek, I think it is harder than you let on: “if you want optimum results, you’d better know what you’re doing or pick implementations that do it right,” So what does “do it right” mean? For sure, there are implementations out there that have paid attention to timestamping accuracy where a vendor implements stuff in their Rx that can compensate whatever their own Tx introduces in terms of timing inaccuracy. But there is more than one way to skin this particular cat, and an Rx is not able to compensate everything that any other vendor’s Tx might do. Having higher timestamping accuracy across a link with the Tx and Rx from different vendors in general isn’t possible based on what is written in the standard. There are two elements that have been clarified in recent years: how you deal with multi-lane interfaces (you consider the PTP message as if it had been received on the slowest PHY, and hence after the deskew point), and how you deal with PHYs with FEC (sublayer delays are reported as if the PTP message were at the beginning of the FEC codeword). So hopefully most implementations done after the introduction of those clarifications in the standard are doing those elements in the same way. But there is a lot more than this: idle insertion/deletion, for example, affects timestamping accuracy, and while the standard tells you where idles are allowed to be inserted or deleted, it gives you no concrete criteria for how to decide when to insert or delete, and gives you no guidance about how inserted or deleted idles are distributed. If the Rx knows what the Tx is doing, it may be able to compensate. If the Rx doesn’t know the details of what the Tx does, there isn’t anything you can do. Regards, Steve From: Steve Gorshe <Steve.Gorshe@xxxxxxxxxxxxx> Hi Marek, Thanks for your good follow-up comments. The color made it through. Some of comments are in-line below with yours. At a high level, we agree with your comments regarding implementation details. That’s part of the point we are making. Without some guidance, different implementation choices can impact the achievable timestamp accuracy. We envision that one possible output of a TF could be an 802.3 appendix that documents the things that could limit timestamp accuracy (e.g., a “user beware” explanation), and possibly offer guidance on implementation approaches for those interfaces that require optimized timestamp performance. In other words, we agree with your statement “if you want optimum results, you’d better know what you’re doing or pick implementations that do it right,” but believe that it is best if 802.3 provide some guidance regarding how to pick such an implementation. Without that, there is a danger that Ethernet will be rejected for some applications due to not being able to guarantee the timestamp accuracy that it could potentially achieve. Best regards, Steve From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx] External E-Mail Thank you, Steve Inline with [mh0611] tags. Not sure if the color makes it through though Marek From: Steve.Gorshe@xxxxxxxxxxxxx <Steve.Gorshe@xxxxxxxxxxxxx> Dear Marek, Thanks for your review and comments. Please see my responses in-line below. The issues are somewhat subtle, and only become significant when high accuracy is required. I hope this adds clarity. Let me know if you have any follow-up questions. Best regards, Steve From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx] External E-Mail Dear all, I have been trying to parse through the deck on PTP "issues", as presented at the last NEA meeting in Salt Lake City (http://www.ieee802.org/3/ad_hoc/ngrates/public/19_05/tse_nea_01a_0519.pdf), and come up with just one or two items that warrant any work. Perhaps I am misreading the presentation and there is much more to it, but it seems to me that the main "issues" that are supposed to be addressed in the new potential Study Group would be as follows:
If I am reading these right, I thought that the second item was already addressed before, through updates to Clause 90. Perhaps I am missing the point that the presentation as trying to make, given that it is buried in so much detail it is hard to parse. [Steve Gorshe] The previous update to Clause 90 addressed the impact of end-to-end skew differences between different lanes on a multi-lane interface. The issue here is a bit more subtle and only becomes a noticeable issue when high accuracy is required. As illustrated in Appendix 4 of our presentation, there are different ways to do the distribution of symbols to lanes. One method is analogous to a serial-to-parallel converter in which the entire group of N symbols for the N lanes are gathered and sent to the lanes simultaneously. (See the Method 1 slide in our presentation.) Consequently, the waiting time in the distribution buffer is dependent on the lane number. This creates an uncertainty, since it is not specified whether the transmitter should use the actual MII-MDI delay associated with the lane carrying the SFD, or use a constant delay that reflects the average for the lanes. Another approach is to minimize delay by sending a symbol to its lane as soon as it arrives in the distribution buffer, which results in each lane having essentially the same waiting time. Since none of this is specified in 802.3, the transmitter and receiver could choose different approaches, which would lead them to make different MII-MDI delay calculations, hence limiting the achievable timestamp accuracy. [mh0612] This sounds like an implementation detail to me, i.e., if you want optimum results, you’d better know what you’re doing or pick implementations that do it right. We have usually shied away from specifying such details. However, looking at page 43 and reading all the tiny legends, it does not seem to me that the drawings show actual situation, even Option A (I assume this is how you interpret the operation right now). Looking at 119.1.5, a single xMII transfer is presented to PCS, but inside of the PCS you have 256B/257B transcode (as one function) which does buffering incoming codewords until enough data is there to transcode and send out. Take a look at 119.2.4.2 64B/66B to 256B/257B transcoder and the statement “The transcoder constructs a 257-bit block, tx_xcoded<256:0>, from a group of four 66-bit blocks,” In your drawing, you seem to present a situation where the first transfer on xMII just “falls through” PCS and hits PMD with zero delay. I do not think that is the case. There is transcoding and FEC encoding delay in the path. [Steve Gorshe] Interesting point regarding the 256B/257B transcode. However, not all the interfaces of interest use 256B/257B. Regarding the transcoding and FEC delays: If you looked at the “bits on the wire” you would see a variable delay impact on the timestamp from the source transcoding and FEC encoding. However, each, occurs regularly and the sink FEC decoding and transcoding exactly remove the variability. The result is a constant end-to-end delay impact that can be taken into account. This has already been addressed. On item 1, again perhaps I am reading it wrong, but it seems like it would cause a fixed delay that should be trivial to account for in any implementation – it seems to be nothing more than a shift in the reference point that happens one each and every frame in exactly the same way. If that is a case, it seems it is a non-issue, really. [Steve Gorshe] Your assessment is accurate for the lower rate simpler PHYs. However, beginning with 100GBASE Ethernet, the PHYs became much more complicated and this had subtle implications for achieving high accuracy for timestamps. The 802.1 and 802.3 reference points are always located in separate 64B/66B blocks, per Clause 81.2.2 (i.e., the Start is in a control block that includes the preamble, and the control block containing the SFD immediately follows it). This means that AMs, which can occur at any point within a packet, can also land between the 802.1 and 802.3 reference points. [mh0612] Even if the AM lands between both reference points, the expansion (stretch) caused by the AM insertion on the Tx side should be compensated by the contraction on the Rx side, where the AM is removed and original bit stream recovered. 108.5.2.4 states clearly that “Room for codeword markers is created by the rate compensation for codeword markers in the transmit direction process (see 108.5.2.2) such that the bit rates at the input and the output of the 25GBASE-R RS-FEC sublayer are equal.” [Steve Gorshe] Yes, the bit rates are equal, but the delay impact for the packets carrying the timestamp is not necessarily equal. That’s the problem. A more subtle and difficult AM-related issue can be seen from Figure 119-2. Both AM insertion/removal and rate matching are performed within the PCS (i.e., between the MII and MDI). A typical transmitter removes an adequate number of Idles to create the bandwidth required by the AMs and the receiver inserts Idles to fill the space after removing the AMs. However, there is no specification in 802.3 for how this should be done. For example, the transmitter could be implemented to remove Idles on a quasi-regular basis between AM appearances in order to minimize its impact on FIFO depth, and the receiver could be implemented to insert a burst of Idles equal to the AM size at the next opportunity. Consequently, the transmitter and receiver would have different MII-MDI path delays, which can impact timestamp accuracy. [mh0612] This sounds like an implementation detail to me, i.e., if you want optimum results, you’d better know what you’re doing or pick implementations that do it right. We have usually shied away from specifying such details. Thank you for the clarification Marek -----Original Message----- Dear Colleagues, The following request for agenda time for a call for interest has been received from Steve Gorshe. It will be discussed at the IEEE 802 LMSC July 2019 Plenary meeting in Vienna, Austria. If you have any questions please get in touch with either Steve Gorshe <steve.gorshe@xxxxxxxxxxxxx> or myself directly. ---- Applications in which Precision Time Protocol (PTP) (e.g., IEEE Std 1588 or IEEE Std 802.1AS) is carried over Ethernet interfaces have become increasingly important. A growing number of applications benefit from being able to communicate frequency and time synchronization information over Ethernet. Emerging important potential Ethernet applications such as 5G mobile radio access networks require increased PTP accuracy. Unfortunately, the increased complexity of several recent IEEE Std 802.3 PHYs have inadvertently introduced limitations or degradations of the potential PTP accuracy. In some cases, the decreased PTP accuracy is related to a discrepancy between IEEE Std 802.3 and IEEE Std 802.1AS/1588 reference points. Addressing these issues will increase the scope of applications in which Ethernet can be deployed. This Call for Interest is to assess the support for the formation of a Study Group to explore the potential markets requirements and feasibility of amending the IEEE 802.3 Ethernet standard to support high accuracy frequency and time synchronization. ---- The call for interest will take place during the IEEE 802.3 Opening Plenary on the morning of Monday 15th July. A call for interest consensus building meeting has been scheduled to occur from 19:30 to 20:30 on the evening of Tuesday 16th July. The vote to determine if a Study Group will be formed will take place at the IEEE 802.3 Closing Plenary on the afternoon of Thursday 18th July. Best regards, David Law, Chair, IEEE 802.3 Ethernet Working Group Phone: +44 1631 563729 Email: mailto:dlaw@xxxxxxx ________________________________________________________________________ To unsubscribe from the STDS-802-3 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3&A=1 To unsubscribe from the STDS-802-3-DIALOG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DIALOG&A=1 To unsubscribe from the STDS-802-3-DIALOG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DIALOG&A=1 To unsubscribe from the STDS-802-3-DIALOG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DIALOG&A=1 |