RE: [EFM-P2MP] Definition of Timestamp in MPCP messages
Hi,
the describing text is fine but the sign of offset should be different in the first equation. Thus, in ONU
local time = received timestamp + offset
instead of
local time = received timestamp - offset
This is because ONU should act as if it had updated the local clock when the first byte of timestamp came although it does it later in time.
The second equation I agree with.
If one considers the corresponding situation in OLT, the equations would be as follows:
Transmitting:
time stamp = local time + offset
Receiving:
time of receiving packet = local time of OLT - offset.
Some people may think pondering the equations is a waste of time when the offsets could be embedded in round trip time (RTT). As an answer, so far I have recognized three advantages in doing the effort:
-Minimize delay jitter caused by registration periods because no extra vendor specific offsets are added to real RTT.
-Standard gives useful physical topology information easily regardless of the manufacturer.
-EPON technology could offer transport of absolute time without having to know and compensate time stamp errors which again vary between equipment manufacturers.
Antti
> -----Original Message-----
> From: ext Glen Kramer [mailto:gkramer@ucdavis.edu]
> Sent: 26 April, 2003 00:19
> To: 'Bob Gaglianello'; stds-802-3-efm-p2mp@ieee.org
> Subject: 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
>
>
>
>