| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Perhaps you missed my first comment. I copy it here for your convenience (empheis added). In 10G-EPON we incorporated the Data Detector mechanism to determine when
the beginning of the burst should occur. The mechanism depended on a delay line that essentially matched the duration of burst preamble, burst delimiter and laser on time (i.e., sync time).
In 10G-EPON this was a fixed duration. We have now made that duration
variable and of arbitrary size through the setting of SP1, SP2 and SP3 and any repeats. What will the ONU be expected to accommodate with respect to maximum delay
needed? Without placing a bound on this total time I don’t see how we can claim
technical feasibility. If some OLT vendor decides a very long sync time is OK per the standard and an ONU cannot accommodate that long time interoperability
is not achieved, neither device is non-compliant and we have not achieved our goals. Best Regards Duane From: Glen Kramer [mailto:glen.kramer@xxxxxxxxxxxx]
Duane, First, a suggestion to reduce the field size. Then limiting the total of SP1, SP2, and SP3. It is clear you are trying to solve some problem, but it is not clear
what that problem is. Can you explain it first? For the SP1, SP2, and SP3 lengths, we must have individual limits. The limit on the total size will naturally follow from that. Thank you, -Glen From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
I suggest we limit the aggregate of SP1 + SP2 + SP3 to 2.5 us. This is over twice what Glen suggested (and what was considered easy to accomplish in 2002 where
the default was ~850 ns). Best Regards Duane From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx]
All the points Glen is bringing up are very valid. Just to add, should any value range restriction be needed, we can set the range in the field definition on the draft, and
be done with it. However with pad still available, there is very little reason to skimp on field size.
Marek From: Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxx>
Because There is plenty of padding left in a message. If we don’t use it for any fields, we just send zeroes anyway. All fields are even, so the frame can be parsed on word boundary instead of byte boundary. Vendors/developers can use the values exceeding the spec limit for system bring-up/debugging (assuming both ends of the link can handle
this). What would be the reasons to reduce these fields to 1 byte? Thank you, -Glen From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Glen, I would be happy with these values, at least for starters. But then my question become why do you need 16 bits to express a number that can be easily expressed
in 7 bits? Best Regards Duane From: Glen Kramer [mailto:glen.kramer@xxxxxxxxxxxx]
I am not sure what the issue is. The bound comes from the definitions of Ton, Treceiver_settling, and Tcdr. I am sure we will have a separate discussion on that.
The bound does not come from the MPCPDU field size. In 10G-EPON, SyncTime field was 2 bytes, but the maximum allowed value was 76 TQ (800 ns Treceiver_settling, 400 ns Tcdr, and 16 ns Burst Delimiter).
The only thing that needs to change in Marek’s presentation is that it should not say that the entire range from 0 to 2^16 is allowed. It does say it now. Thank you, -Glen From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Marek, The point is not that the OLT has to use both bytes, the point is it legally can and the ONU is duty bound to accommodate that. Without some upper bound that
can come to over 2 seconds of delay. Clearly this is excessive. Best Regards Duane From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx]
Duane, What would be then "reasonable"? It is not like OLT has to use all 2 octets provided for specific values. Marek On Wed, Apr 18, 2018 at 11:51 AM, Duane Remein <Duane.Remein@xxxxxxxxxx> wrote:
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 |