RE: [EFM-P2MP] Definition of Timestamp in MPCP messages
Hello Hidekazu,
subtraction of four byte value once or twice for every gate message (worst case once per 10 us when 64 ONUs follow 1.5 ms cycle) sounds simple enough so I doubt it brings much complexity. However, if the subtractions or additions are really considered to be an issue, the decision should be such that the variation between vendors would remain within close limits and follow the 4 x 32 ns round trip timing error discussed in Dallas. Only this way the registration period induced delay jitter can be avoided.
Thus, we have to agree upon a reference point in messages, the precision required, and, if necessary, offsets that are same for every vendor.
Antti
> -----Original Message-----
> From: ext Hidekazu Miyoshi [mailto:miyoshi-hidekazu@sei.co.jp]
> Sent: 29 April, 2003 13:31
> To: stds-802-3-efm-p2mp@ieee.org
> Subject: 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
> > > >
> > > >
> > > >
> > > >
> >
> >
>
>
>