| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Duane,
You didn’t answer any of my questions. My first question was about the granularity of the delay variation targets.
You said earlier that you want to constrain delay variation per individual sublayers. But the examples you are showing always clump MPCP, MAC, and MCRS together, and PCS and PMA together. So, it looks to me you allow for only the following two implementations: 1) {MPCP/MAC/MCRS/PCS/PMA} + PMD 2) {MPCP/MAC/MCRS} + {PCS/PMA} + PMD
Is this your assumption, or do you have something else in mind?
My second question was about how to measure separate delay variation components. But maybe a better point to start is to clarify the definition of delay variation? Are you talking about packet delay variation, bit delay variation, 64b block delay variation, or 257b block delay variation?
For example, when a 2000-byte packet is presented to a MAC for transmission, it is presented all at once using MA_DATA.request primitive. From the MAC, this packet is played out one bit at a time using the PLS_DATA.request primitive. If the MAC is transmitting at 25Gb/s, the delay variation between the first bit of the frame and the last bit of the frame is 80 ns or 31.25 EQT (even without the RATE ADJUST EQs slowing the MAC).
So, before proposing any delay variation values, please clarify how delays are measured. What is the exact epoch when delay starts and the exact epoch when delay ends, for each individual delay constraint that you want to specify?
-Glen
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
I will attempt to respond to Marek’s, Glen’s and Marek’s replay in this one response. First off I am not suggesting that the 81 ns in insufficient, just the opposite, I believe it is more than sufficient but that is true only if the PHY components are reasonable designed. Currently there is no bound for delay variation (DV) through the PHY (all section are TBD). So even an unreasonable design that allows 50-60 ns of DV is compliant. What I’m trying to do is put a bound on the amount of DV allowed in an implementation. I would expect most SOCs to include both the MAC and the PHY and not expose the xMII. Given this is the case how would you measure the DV from the MCRS as opposed to that contributed by the PMD or PCS/PMA? You can’t so why should we specify it that way? If I decide to design only the PCS/PMA what if my target? What about if I am only designing the PMD or only the MAC? If I am a system implementer what is the total I’m allowed, the sum of the parts or something less? If we really want to do the latter with the assumption that a full system gets the sum of the parts I could go with that but we do need numbers in the spec not just “TBD”. If you look at my proposal is neither more nor less “dissected” than what we have in the standard now; each layer is well defined. I just added a target for individual sub-systems and put it all into a single table which in my mind is clearer. Best Regards Duane
From: Mark Laubach [mailto:mark.laubach@xxxxxxxxxxxx]
Hi Duane,
I’m equally having trouble understanding why something more complicated (more dissected?) than what was done in 75.3.1.1, 76.1.2, and 77.3.2.4 is needed (for us: 141.3.1.1, 143.4.3 and 144.3.1.2). Why does the same level of specification not work for NGEPON?
Cheers, Mark
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
I would like to begin an open discussion regarding how we specify Delay constraints in our draft (also see comment #434 againsse D1.2 from the Spokane meeting). When I crafted this proposal I made the assumption that a supplier may be providing one or more layer functions and would need to know the amount of delay variation allocated to the partial system they were supplying. Thus the proposed table provided allocations for everything from any single layer/sub-layer to an entire system. I broke the entire transmit data path into MAC/MAC Control/ MCRS (labeled MCRS for simplicity), PCS/PMA, PMD, PHY and MAC to PHY (i.e., the entire tx path). One of the arguments against this idea was that our skew management system will remove any potential delay variation. This is true up to a point, that being the amount accommodated by the 32 slots in our receive skew buffer or 81.92 ns total. While it is true that the receiver will remove this skew we still need to constrain the transmitter so that the total skew is less than this 81.92 ns. It was also argued that a PMD designer should not have to look in the MPCP clause to get a requirement. I find this argument somewhat contradictory as we often write specifications that reference other clauses in the 802.3 book. We even reference other specification when it is appropriate (for example we don’t spec the fiber itself). So pointing to another clause should not be a problem. I’m not at all opposed to moving the proposed allocation table to Cl 141 but we need it somewhere with proper cross-references form other layer clauses. I’m also very open to discussing the actual values in the table. For your convenience I’ve included the proposed table below. Assuming we can come to an agreement I will re-submit a comment on this topic against D1.3. Best Regards, Duane
FutureWei Technologies Inc. Director, Access R&D 919 418 4741 Raleigh, NC
To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1 To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1 To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1 | ||||||||||||||||||||||||||