Re: [AVTCORE] Leap seconds

[Colin Perkins <[e-mail]>]

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



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/