Jouni:
I think 1ns is sufficient for the foreseeable future. For the unforeseen future, a RESERVED bit could be used to signal the use of a different packet header, which has a timestamp field that supports higher precision.
I think we should add more RESERVED bits to the header as, almost certainly, many new features will be created as RoE evolves.
Regards,
Rich
From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of patrick diamond
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? How will the sending system know the transit time of that
specific packet to plan for the playout with 1nS of accuracy?
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