| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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 | ||||||||||||||||||||||||||