Re: [AVTCORE] Leap seconds

RFC 5905 indicates that the 64-bit NTP timestamps used by the NTP protocol
are a bit more complex than that. Specifically, these NTP timestamps have
discontinuities around leap seconds. RFC 3550 does not spell it out exactly
but I assume the 64-bit NTP timestamp in the RTCP sender report sould behave
according to the definition in RFC 5905.

Kevin

On Wed, Sep 14, 2011 at 1:02 PM, David Singer <singer@apple.com> wrote:

>
> On Sep 14, 2011, at 11:49 , Kevin Gross wrote:
>
> To be clear, "Those issues" refers to the year 2038 problem.
>
> By my reading, my original concern about leap seconds is not addressed in
> this excerpt or anywhere else in the RFC. I'm hoping to see some additional
> discussion about that.
>
>
> NTP timestamp are, as I recall, simply counts of seconds and fractions of
> seconds since a well-defined origin.  How you choose to interpret and
> display that count is entirely up to you; I don't think RTP really cares
> which year something happened in, for example.  You could use any calendar
> system you like..
>
>
> I do recognize that the unsynchronized clock option allows me to replace
> NTP time with 1588 time. Apparently I should set the MS bit in the
> timestamps if I do this (and possibly expect problems after 2038).
>
> Kevin
>
> On Wed, Sep 14, 2011 at 12:11 PM, Stephen Casner <casner@acm.org> wrote:
>
>> Those issues are addressed in RFC 3550:
>>
>>   Wallclock time (absolute date and time) is represented using the
>>   timestamp format of the Network Time Protocol (NTP), which is in
>>   seconds relative to 0h UTC on 1 January 1900 [4].  The full
>>   resolution NTP timestamp is a 64-bit unsigned fixed-point number with
>>   the integer part in the first 32 bits and the fractional part in the
>>   last 32 bits.  In some fields where a more compact representation is
>>   appropriate, only the middle 32 bits are used; that is, the low 16
>>   bits of the integer part and the high 16 bits of the fractional part.
>>   The high 16 bits of the integer part must be determined
>>   independently.
>>
>>   An implementation is not required to run the Network Time Protocol in
>>   order to use RTP.  Other time sources, or none at all, may be used
>>   (see the description of the NTP timestamp field in Section 6.4.1).
>>   However, running NTP may be useful for synchronizing streams
>>   transmitted from separate hosts.
>>
>>   The NTP timestamp will wrap around to zero some time in the year
>>   2036, but for RTP purposes, only differences between pairs of NTP
>>   timestamps are used.  So long as the pairs of timestamps can be
>>   assumed to be within 68 years of each other, using modular arithmetic
>>   for subtractions and comparisons makes the wraparound irrelevant.
>>
>> The timestamp is not required to be synchronized with UTC at all.  For
>> some applications it would be convenient to use UTC in order to
>> synchronize the RTP stream with some other kinds of events, but RTP
>> does not require it.
>>
>>                                                        -- Steve
>>
>> On Wed, 14 Sep 2011, Allison, Art wrote:
>>
>> > As I understand it the UTC clock will monotonically increase after
>> > January 2017 (no more leap seconds). What happens at 03:14:07 UTC
>> > <http://en.wikipedia.org/wiki/Coordinated_Universal_Time>  on Tuesday,
>> > 19 January 2038 (32 bit count overflow) will need to be addressed by
>> > someone, - your guess if any equipment being built today will be in
>> > service then.
>> >
>> > See
>> >
>> http://www.agi.com/downloads/resources/white-papers/Debate-Over-UTC-and-
>> > Leap-Seconds.pdf  for more information.
>> >
>> >
>> >
>> >
>> >
>> > Art Allison
>> > Senior Director Advanced Engineering, Science and Technology
>> > National Association of Broadcasters
>> > 1771 N Street NW
>> > Washington, DC 20036
>> > Phone  202 429 5418
>> > Fax  202 775 4981
>> > www.nab.org <blocked::http://www.nab.org>
>> > Advocacy  Education  Innovation
>> >
>> > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
>> > Kevin Gross
>> > Sent: Wednesday, September 14, 2011 1:22 PM
>> > To: avt@ietf.org
>> > Subject: [AVTCORE] Leap seconds
>> >
>> >
>> >
>> > I am working on a means of using an IEEE 1588 timebase for RTP
>> > streaming. I am aware of IEEE 1733 and will use that if necessary. First
>> > I am exploring using existing NTP mapping function in RTCP sender
>> > reports. While researching how to translate a 1588 timestamp to its NTP
>> > equivalent, I was reminded of the wrinkle leap seconds put into things.
>> >
>> >
>> >
>> > The RTCP sender report maps RTP timestamps to NTP timestamps. RTP
>> > timestamps are monotonically increasing. The RTP timestamps are based on
>> > UTC and have an occasional wobble due to leap seconds. During the leap
>> > second, there is an ambiguous mapping between RTP and NTP/UTC. I find no
>> > recommendations in RFC 3550 for dealing with this.
>> >
>> >
>> >
>> > --
>> >
>> > Kevin Gross
>> >
>> > AVA Networks
>> >
>> > +1-303-447-0517
>> >
>> >
>> >
>> >
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
>>
>
>
>  _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
>

-- 
Kevin Gross
AVA Networks
+1-303-447-0517