Re: [AVTCORE] Leap seconds

[Marshall Eubanks <[e-mail]>]

On Wed, Sep 21, 2011 at 12:32 PM, David Singer <[e-mail]> wrote:

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

And I don't think that is what you are going to get if the interval crosses
a leap second.

Regards
Marshall



> 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 <http://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.
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>
>