Re: [AVTCORE] Leap seconds

[Kevin Gross <[e-mail]>]

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