Re: [AVTCORE] Leap seconds

If the David Mills' documents are taken as normative...

On Mon, Sep 19, 2011 at 12:01 PM, Kevin Gross <kevin.gross@avanw.com> 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
> +1-303-447-0517
> Media Network Consultant
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
>