Re: [AVTCORE] Leap seconds

[David Singer <[e-mail]>]

On Sep 20, 2011, at 15:21 , Colin Perkins wrote:

> I guess I'm confused. RTP was intended to use NTP *format* timestamps, but intentionally said nothing about synchronisation to any particular time source. I don't think it's valid to assume that the NTP format timestamps conveyed in RTP are synchronised to UTC, TAI, or anything else, *unless you have some explicit signalling to state that*.
> 
> Colin

Yes, what RTP needs for its operation is correct measurement of interval durations.

Indeed, I think that for RTP purposes it's important that taking two sender reports -- RTP/'NTP' timestamp pairs -- we can form the difference between the two RTP values, and the two NTP values, and determine, for example, if the source's RTP clock is running slightly fast or slow.  If the NTP interval incorrectly counts seconds, this could be ... confusing.

> 
> On 20 Sep 2011, at 15:45, Kevin Gross wrote:
>> Magnus,
>> 
>> Thanks for thinking this through. The situation is worse if one of the system clocks has a bad leap-second implementation. In that case, it could be until the next NTP clock update before things get back to normal. On the other hand I think if senders and receivers are all aware where the leap second lives, and we make appropriate recommendations, a system can glide through it without disruption. On the third hand, I'm not convinced leap-second awareness for media applications is a reasonable requirement.
>> 
>> Things certainly are easier on a TAI timebase. I started picking into this because I want to use IEEE 1588 time instead of NTP for some work I'm doing. I figured it would be best for interoperability if I recommended translating the 1588 timebase to the NTP epoch. When I realized that NTP timestamps were UTC, it scuttled that idea but also opened this can of worms.
>> 
>> Kevin Gross
>> 
>> 
>> On Tue, Sep 20, 2011 at 2:02 AM, Magnus Westerlund <[e-mail]> wrote:
>> On 2011-09-19 22:07, Kevin Gross wrote:
>> > Yes, well, there it is in all the gory detail.
>> >
>> > The point I'm try to get to is that any behavior that doesn't move the
>> > timestamp forward at a constant rate will be a problem for RTP. You
>> > appear to be reading it as I have. NTP time is UTC time and so there's
>> > non-uniform behavior around leap seconds.
>> 
>> Assuming that the NTP clock freezes or semi freezes during the leap
>> seconds I see two effect happening.
>> 
>> One issue is that an system reading it's clock during the leap second
>> itself will get different values depending on if the system uses true
>> NTP time or POSIX time. Thus potentially creating up to a second of
>> mismatch due to this.
>> 
>> The second issue appears to be that if the two systems are not precisely
>> aligned the leap second will appear to occur at different time from a
>> outside observer. That will result that the system that first implements
>> the leap second will appear to be out of sync with 1 second until the
>> second system also performs the leap second. Thus you suddenly see a 1
>> second sync correction that the receiver system might start correct for,
>> then that difference disappears when the other system also have had its
>> leap second event. Thus resulting in adjusting back again.
>> 
>> The above can cause different media streams to be out of sync at the
>> receiver for the time when only one of the media stream's SR has been
>> delivered.
>> 
>> I would note that leap seconds are rare. They have occurred 24 times
>> since 1970. And there has been only 2 during the 2000 decade.
>> 
>> From my perspective, unless you have a really high performance
>> application, the leap second event will at most cause some sync
>> adjustments with potentially media out of sync that will be corrected as
>> soon as both sender and receiver has passed the leap second event and
>> SRs has been delivered in both cases.
>> 
>> I think the reasonable thing to do is simply to ignore SRs that indicate
>> an approximately 1 second adjustment on a media stream when in close
>> proximity to a leap second event. This would works fine as long as the
>> two involved nodes would not be more out of sync than the guard period
>> where this algorithm is active.
>> 
>> Cheers
>> 
>> Magnus Westerlund
>> 
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone  [phone]
>> Färögatan 6                | Mobile [phone]
>> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>> ----------------------------------------------------------------------
>> 
>> 
>> 
>> 
>> -- 
>> Kevin Gross
>> [phone]
>> Media Network Consultant
>> AVA Networks - www.AVAnw.com, www.X192.org
> 
> 
> -- 
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt

David Singer
Multimedia and Software Standards, Apple Inc.