Re: [AVTCORE] Leap seconds

[Qin Wu <[e-mail]>]

Hi,
I think this is a good proposal since this helps RTP node to know if leap seconds really affect itself. The questions are:
Does this help the RTP node to fix leap seconds? what RTP node will do if it knows the leap seconds affect itself?
Another questions are if we rely on two continuous sender reports, what if the second sender report in them  is lost 
during leap seconds event? what if the seond sender report is delayed due to congestion during the leap seconds event?
How it is accurate?

Regards!
-Qin

  ----- Original Message ----- 
  From: David Singer 
  To: Colin Perkins 
  Cc: Magnus Westerlund ; Marshall Eubanks ; [e-mail] 
  Sent: Thursday, September 22, 2011 12:32 AM
  Subject: Re: [AVTCORE] Leap seconds




  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.




------------------------------------------------------------------------------


  _______________________________________________
  Audio/Video Transport Core Maintenance
  [e-mail]
  https://www.ietf.org/mailman/listinfo/avt