RE: [EFM-P2MP] Definition of Timestamp in MPCP messages
Hello P2MPers,
I think this topic addresses an interesting point. Below is my current
opinion.
I agree to specify a reference point in the standard. But I don't think
this sort of calculation is necessary.
> be different in the first equation. Thus, in ONU
> local time = received timestamp + offset
> instead of
> local time = received timestamp - offset
The reason is such calculation introduces a complexity in
implementation. In my opinion, it is not necessary that RTT includes
only a propagation delay. RTT could contain a part of a transmission
time and a reception time and a certain delay of the lower layer as long
as these are constant.
Regards,
Hidekazu
Hidekazu Miyoshi
Sumitomo Electric Industries, Ltd.
> -----Original Message-----
> From: owner-stds-802-3-efm-p2mp@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm-p2mp@majordomo.ieee.org] On Behalf Of
Glen
> Kramer
> Sent: Tuesday, April 29, 2003 3:36 AM
> To: antti.pietilainen@nokia.com; stds-802-3-efm-p2mp@ieee.org
> Subject: RE: [EFM-P2MP] Definition of Timestamp in MPCP messages
>
>
> Antti,
>
> > 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.
>
> We both are correct. I assumed the offset can be negative.
>
> With my previous e-mail I wanted to emphasize the following
> point:
>
> Typically, entire msdu should be ready before TransmitFrame
> function is called. That means that placing timestamp value
> into MPCP PDU should be done (at least in the state diagram)
> before the first bit of the frame is transmitted.
>
> On the receiving end, the situation is reversed. The
> received frame will become available to MAC Control sublayer
> only after the entire frame is received by the MAC, and
> frame's validity is verified.
>
> The way the state diagrams are drawn now, the timestamp is
> set before frame began transmission, and frame reception
> time is marked after the complete frame has been received.
> This would lead to the measured RTT increased by approx. two
> frame transmission times (~1us). Then, during normal
> granting, when the OLT pre-compensates "grant start time",
> it will subtract the "measured" RTT which is by about 1us
> larger than the real RTT. This most likely is to cause a
> collision with previous ONU's transmission.
>
> The above formulas are a particular implementation that will
> fix the problem. In the standard it is enough to specify
> that placing timestamp in an MPCP frame, and detecting frame
> reception time should be done relatively to some fixed point
> (called "reference point").
>
> It is not necessary for OLT and all ONUs to have the same
> reference point, but it is mandatory that this point is the
> same for setting timestamp and marking frame reception time
> in within each device.
>
> I'd like to hear more opinions about this.
>
> Thanks,
> Glen
>
>
>
>
> >
> > 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
> > >
> > >
> > >
> > >
>
>