Re: [AVTCORE] Leap seconds

OK, I am not an expert, but 1305 does say:

The insertion of leap seconds in UTC and subsequently
into NTP does not affect the UTC or NTP oscillator, only the conversion
to conventional civil UTC time.

On Sep 14, 2011, at 12:54 , Kevin Gross wrote:

> 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
> 

David Singer
Multimedia and Software Standards, Apple Inc.