Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
[Resend, now that I’ve subscribed to Dialogue email list] From: Steve Gorshe - C33336 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. 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. 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. 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 |