| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi George, I support the Proposal and Presentation. Thanks, William From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Colleagues, I will be remote next week, attending the NFPA first draft meetings, and unfortunately unable to be in person at the ISAAC meeting. I hear internet at the NFPA hotel isn’t as good as we have for our 802 meetings, so I am not
quite sure how good my interaction will be. Hence this email to explain the background of a presentation I requested and submitted to Jon, hopefully which fits into the needs of our project and allows us to move forward. In discussions with individuals familiar with imaging sensors (and roadmaps) and individuals familiar with PHYs, it has seemed desirable to target a data rate between 10 and 25 Gbps from the camera. Each additional Mbps that we add to
the PHY’s load makes it a little harder, and, hence it is best to ‘right-size’ the PHY speed. I had thought that this would not be possible in our current framework because it would be a ‘new Ethernet rate’ – something outside a ‘physical layer project’.
Others may have voiced similar opinions, but as of our last interim meeting, some of us began to see a way through.
In discussions with David Law, Geoff Thompson, Jon Lewis, and others, we came to the realization that this is a little different than a ‘new rate’ (typically ‘higher rate’) study group and project. We tightly constrained the study group
to physical layer and to optimize for an application. We noted that the clocked xMII (e.g., XGMII, 25GMII, or possible 15GMII) comes on the PHY side of the RS, that clock is clearly a physical layer interface. The other side (MAC side) of the RS is defined
by ‘rateless’ primitives without a specified rate or timing, and the RS converts between the ‘rated’ and the ‘rateless’. There MAC parameters are tabulated in clause 4 (Table 4-2), but there was no need or desire to change them from the span that is defined
already for Ethernet speeds from 2.5Gbps to 400 Gbps. In our discussions it seemed we had general agreement that a physical layer study group that fits within the existing rate structure of Ethernet between two specified RS rates, could define a new RS (fitting
into the existing clause 4 tables), provided the PAR scope was written to refer to rates relative to the Physical layer (i.e., at the MAC/PLS service interface or within). I have prepared a presentation (and sent to Jon for posting) explaining this, and,
more importantly, proposing PAR language. Note that there is still an important thing to discuss. While I have written the proposed PAR scope for 15 Gbps, because that is the maximum rate that has been supported by application presentations, when we talk about rates we often talk
about the video data rate, which may be increased by framing, packetizing, and protocol overhead. It may be prudent to either increase the referenced rate in the PAR a little to provide margin for this, or, I have provided a backup option which instead references
the video data rates. These both would be useful for discusion in St. Petersburg. I have provided places to add your name as a supporter of the entire presentation, or of just the proposal part. You can do either – the important thing we need to gauge support for is the proposal, and sometimes when there is a lot of
technical matter, people are uncomfortable supporting all of a presentation. Therefore, if you wish to support either the presentation OR just the proposal part please email me directly AND LET ME KNOW WHICH (or both). Feel free also to email privately with
questions. I am also available by phone or webex today if you wish to talk, but am running around getting ready to leave, like I imagine many of you are. -george George Zimmerman, Ph.D. President & Principal CME Consulting, Inc. Experts in Advanced PHYsical Communications 310-920-3860 To unsubscribe from the STDS-802-3-ISAAC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1 To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1 |