Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Duane,  Why is it that you separated all sublayers, except the PCS/PMA? Are they not allowed to be implemented independently? Can you please describe the testing procedure to measure the delay variability in each sublayer that you propose below.  -Glen  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 |