Re: [AVTCORE] Leap seconds

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.

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
>