| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Best Regards Duane From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx]
Just to add to Glen’s point … in 10G-EPON, delay bounds were derived from state diagrams and their interaction. Similar approach should be employed in here, to avoid placing unnecessary delay bounds on sublayers that are not exposed and
not measurable in any way. [drr] – I agree with this idea, it is essentially why I broke thinks up the way I did (i.e., which layer combinations I used) From: Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxx>
More questions below. [GK: ] From: Glen Kramer [mailto:glen.kramer@xxxxxxxxxxxx]
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? [drr] – I was not trying to make any assumption here but maybe had in mind: MAC/MAC Control + RS (really just the RS for this particular parameter), PCS + PMA, PMD, MAC/MAC Control + RS + PCS + PMA, and full
up system (Output of MAC to output of PMD). [GK: ] Seems like an arbitrary decision that PCS shall be always combined with PMA, but MCRS can be separate. If someone can develop MCRS separately from the rest of the chip, why the same does not apply
to PCS or PMA? I am not supporting the idea of separate delay limits per sublayer at all. But I am trying to understand the logic behind you proposal.
[drr] – which interfaces to specify at is hardly arbitrary. The xMII and the PMA-PMD interfaces are all exposed interfaces (although we don’t specify the PAM-PMD interface much, that is left to the Optical Module
standards). We don’t call for exposing the PMA-PCS interface. In reality I don’t expect anyone to build a solution that exposes the xMII, however the standard should not preclude such a solution. 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? [drr] – Good question, I would suggest the important item here is the 257 bit block. (or the EQ that starts such a block for the RS). [GK: ] MCRS doesn’t see 257b blocks, not does it reference the 257b clock. [drr] – I would be happy if we chose to specify the delay variation from any fixed point in the data stream; for example the we could use the ESH at the xMII and the SBD at the PMA and PMD. I uses block size
to avoid significant deviation from our previous practice. These really must all equate to some fixed time period in the end, we could just as easily change the units to ns and do the conversion if that is better.
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).
[drr] – as a reference compare to 60.1.5 Delay constraints, 75.3.1.1 Delay constraints and 76.1.2 Delay constraints. [GK: ] Yes, I know what these clauses specify. And I say that this is exactly what we should also do. One delay variation limit for the PMD (because PMD is in the optical module, always separate from the
ASIC). Another delay variation limit for all the rest of data path under MPCP (i.e., under the timestamping point). That includes MAC, MCRS, PCS, and PMA
all together. [drr] – You will notice that in my table I includes an overall number, I just break it up to avoid confusion should someone decide to produce a specific sub-system.
As a system vendor it is always a pain to allocate a system budget out to component vendors that produce sub-system components and not the whole, each sub-system vendor want the lions share of the pie. The “all together” number you suggest clearly creates
a split between PMD and everything else. That is because as a chip vendor you want to know how much of the pie you get. I’m just suggesting that we don’t discount the chip vendor who wants to do a MAC / PHY solution (i.e., expose the xMII). Here are the arguments why we should not specify separate delay variation limits per sublayer:
1)
State diagrams already provide the information on the delay variability that each process introduces. Specifying a separate number will be confusing, especially if that number is more strict or more
lose than a state diagram dictates. [drr] – I have no problem changing the numbers if some analysis indicates so.
2)
Delays in adjacent sublayers are dependent and inversely proportional. For example, in PCS, when four 64b are packed into 257b block, the first 64b block will experience longer wait time than the last
block in the pack. But when in PMA the 257b block is played out serially to the PMD, the first 64 bits will experience lower delay then the last 64 bits. So, together, PCS and PMA provide smaller delay variation than each of the sublayers separately. Providing
separate delay limits per sublayer will result in greatly exaggerated total allowance than what we really should have. [drr] – This is only true is you look at the small pieces of the data stream relative to each other, which typically isn’t done when measuring delay variation. Typically you
pick some fixed ref point in the data stream as I point out above (like ESH or SBD) 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 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 | ||||||||||||||||||||||||||