RE: [EFM-P2MP] Definition of Timestamp in MPCP messages
Bob,
Another thing to consider is that a frame is not received
until its last bit is received. Thus, MPCP will see
MPCP_PDU only after the MAC received the complete frame and
verified its CRC. In order to set the correct local time (in
ONU) or calculate RTT (in OLT), the MPCP should subtract
some offset from the value of the local clock at the receive
time.
If the timestamp reference point is the first byte of the
timestamp field, the offset value would be approx. 352 ns.
(the time from the reference point to the end of the frame).
Then, at the receiving end (in ONU), the MPCP would set
local time as
Local time = received timestamp - offset.
Alternatively, transmitting end may take the reference point
to be the last bit of the frame. That makes offset at the
receiving end equal zero. But then, the transmitter should
add an offset to the value to the timestamp as below:
Timestamp = local time + offset
Does everybody agree?
Glen
> Folks,
>
> Last night on the Conference call there was a question
> concerning the
> "meaning" of timestamps in MPCP messages. For example,
> does the
> timestamp mean that this is the time that the first byte
> of the message
> is passed on to lower layers, or is it the time the first
> byte of the
> timestamp is passed to lower layers. I thought I would
> begin the
> discussion by asking some of the EPON developers here.
> They gave me the
> following answer to the question:
>
> "In our current implementation, the timestamp is the
> status of the local
> counter at the insertion time which is a couple of cycles
> before the
> timestamp enters the 8b10b encoder. The 8b10b encoder will
> then
> introduce further latency that becomes part of the
> roundtrip delay.
>
> I would prefer a definition of the timestamp as the status
> of the local
> clock at the time of sampling, where the delay between
> time of sampling
> and PMD transmission time of the message (or of the
> timestamp) is
> constant for any EPON compatible olt or onu unit."
>
> Their feeling was that either definition would work, as
> long as it is
> specified in the standard so all will implement
> consistently...
>
> cheers,
> bobg