Re: [AVTCORE] Leap seconds

[Kevin Gross <[e-mail]>]

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.

On Mon, Sep 19, 2011 at 11:10 AM, Marshall Eubanks <
[e-mail]> wrote:

> If the David Mills' documents are taken as normative...
>
> On Mon, Sep 19, 2011 at 12:01 PM, Kevin Gross <[e-mail]>wrote:
>
>> David Singer and I spent some time last week working through this offline.
>> We're using the same sources and coming to different conclusions. We need
>> some help resolving this open question.
>>
>> David's position is that the NTP timestamp continues to increment, with
>> the system oscillator, through a leap second. The leap second is not visible
>> in the NTP timestamp but in a higher layer process that converts NTP
>> timestamps to UTC.
>>
>> My reading is that the NTP timestamp *is* UTC time and that the clock is
>> paused for 1 second and a new timeline established at the leap second. This
>> behavior will either upset or complicate media systems attempting to
>> reference their playback to the NTP timestamps delivered in RTCP sender
>> reports.
>>
>
> Neither or both is true, depending on your taste. (See below.) I would not
> regard a NTP time interval including a leap second as an UTC time interval.
>
> "Thus, determination of UTC time intervals spanning leap seconds will be
> in error, unless the exact times of insertion are known from the NIST table
> and its successors."
>
>
>>
>> RFC 3550 (RTP) does not discuss leap seconds.
>>
>> RFC 5905 (NTP) describes the mechanism used to convey
>> an upcoming leap second but does not appear to discuss timestamp behavior
>> associated with the leap second.
>>
>> The following two references from David Mills (RFC 5905 author) directly
>> discuss leap second behavior:
>>
>>    1. http://www.eecis.udel.edu/~mills/leap.html Section 5
>>    2. Last section of http://doc.ntp.org/4.1.2/leap.htm
>>
>>
> "In this design time stands still during the leap second, but is correct
> commencing with the next second. Since clock readings must be positive
> monotonic, the apparent time will increase by one nanosecond for each
> reading. At the end of the second the apparent time may be ahead of the
> actual time depending on how many times the clocks was read during the
> second. Eventually, the actual time will catch up with the apparent time and
> operation continues normally."
>
> So, the time is frozen EXCEPT that it keeps incrementing by 1 nanosecond
> per read. In older software, that was 1 microsecond / read. If you are
> reading the clock at 90 KHz, that's
>
> - 90 microseconds for a  clock with 1 nanosecond time units, or 8 clock
> cycles
> - 90 milliseconds for a  clock with 1 microsecond time units, or 8100 clock
> cycles
>
> The near frozen polling would continue for that many additional clock
> cycles (plus ~ 800 more for clocks with 1 microsecond time units, to catch
> up with the delay caused by the polling in the catch up interval.
>
> Regards
> Marshall
>
>
>>
>> --
>> Kevin Gross
>> [phone]
>> Media Network Consultant
>> AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org
>>
>>
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/avt
>>
>>
>


-- 
Kevin Gross
[phone]
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org