RE: continuing the discussion on timestamps
Patrick,
See my comments inline:
- Jouni
> From: patrick diamond [mailto:pdseeker@xxxxxxx]
> Sent: Wednesday, March 18, 2015 4:04 PM
> To: Jouni Korhonen; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
> Subject: RE: continuing the discussion on timestamps
>
> Jouni
>
> Hi. If the timestamp is used only for the playout time and the granularity is 1nS, how will the sending system know the value of
> time at the receiving system with 1nS granularity for playout planning?
Sender can only assume that its and receiver's clocks are in sync. There is some sloppiness allowed from the perfect timing in real systems.
> How will the sending system know the transit time of
> that specific packet to plan for the playout with 1nS of accuracy?
Referring to other standards & implementations that have done the similar, negotiating the transit time ("worst" case network delay) could out of scope of this spec. I know it is a lame answer. I would let e.g. 1588 or 802.1AS or similar to provide the network delay information for the RoE endpoints.
- Jouni
>
> Pat
>
>> From: jouni.korhonen@xxxxxxxxxxxx
>> To: STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
>> Subject: continuing the discussion on timestamps
>> Date: Wed, 18 Mar 2015 22:40:43 +0000
>>
>> Folks,
>>
>> Let's continue where we left off in call.. two things I would like to get a better sense of the room is the timestamp
>> granularity/accuracy. I had a proposal for 1ns and not sending timestamp in every packet. Assuming that the timestamp
>> actually serves as a marker when the packet(s) need to be played out from the encapsulation function (e.g. to RE, REC or in
>> some use cases to CPRI mapper - exact location _where_ in encaps/mapper is up to the implementation) I would take 1ns is
>> enough. Between timestamps I proposed using sequence numbers.
>>
>> Comments? Thoughts?
>>
>> - Jouni