| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
The original message bounced for some reason. Resending. Glen From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Dear Jouni, I am CCing Steve Carlson (Chair of former 802.3bf TF) and David Law (Chair of 802.3) to make sure they are aware of this ask and help us craft the wording so there is no misunderstanding when the letter reaches 802.3 at some point of
time. Now, into the gist of the email :) Much as I am interested in the work of 802.3bf (I have been part of this project), the letter includes a lot of text, but little detail. For example, the existing 802.3bf register set does not preclude a "Provision for delays that are
constant but may change each time link is established" - it is up to implementer to either pre-define them at production time, or allow them to be changed at initialization time, based on proprietary measurement techniques. The only requirement for Clause
30 registers is that "The values contained in these registers are valid when the link is established", which is (I believe) what the liaison letter seems to be asking anyway. I believe the third bullet is covered in terms of possible variability, and details
on how "delay resulting from any bit-level misalignment between the clock signal recovered from the serial bit stream and the parallel word upon which the timestamp is generated" would be achieved is obviously left open to implementers in the good ol' Ethernet
fashion. Now, "Sufficiently detailed description of the delays to encourage compatible implementations" is very subjective. 802.3bf and larger 802.3 had pretty long discussion on level of detail, with the involvement of 802.1 TSN representatives,
and the level of detail included in the standard right now was deemed sufficient for any implementer to go and build PHYs supporting 802.3bf functionality. If additional details are needed, it would be most helpful to provide examples of what might be necessary
to facilitate implementations. Finally, the resolution of ns supported currently by 802.3bf is what was deemed technically feasible, especially considering existing PHY implementations. I do believe that 2-16ns stated in the letter is a typo, given that
it is well shorter than attosecond, which is what I am led to believe is the shortest measurement unit of time in physics today (2-27s is shorter than yoctosecond). I do not believe that even for the fastest PHYs supported by 802.3 Ethernet today
we operate at bit times shorter than 1ps, and even then, 1ps resolution requires a whole chain of changes into the PHY to support such measurement precision – something that Ethernet has typically stayed away from. I believe this level of precision may be
achievable in some of Ethernet PHY implementations relying on much better clocks and then designed specifically for this purpose. I do not believe pushing all production PHYs to support such precision is reasonable and justified in terms of resulting cost.
Regards Marek -----Original Message----- Folks, The IEEE 1588 WG would like to cooperate with us (and with IEEE 802.1TSN) to submit a joint request for an improved version of the timing information provided by 802.3bf. See the attached document. We'll discuss the proposal initially in our next biweekly call on 4/28/15 and continue in coming FtF meeting in June.
- Jouni -- Jouni Korhonen, CTO Office, Networking, Broadcom Corporation O: +1-408-922-8135, M: +1-408-391-7160 |