IETF Logo Mail Archive

Re: [AVTCORE] Leap seconds

Kevin Gross <kevin.gross@avanw.com> Mon, 19 September 2011 15:59 UTC

Return-Path: <kevin.gross@avanw.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BE421F8C8B for <avt@ietfa.amsl.com>; Mon, 19 Sep 2011 08:59:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.303
X-Spam-Level:
X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Z03vHN9X7x9 for <avt@ietfa.amsl.com>; Mon, 19 Sep 2011 08:59:07 -0700 (PDT)
Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 5AAA921F8C81 for <avt@ietf.org>; Mon, 19 Sep 2011 08:59:06 -0700 (PDT)
Received: (qmail 5904 invoked by uid 0); 19 Sep 2011 16:01:30 -0000
Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by cpoproxy2.bluehost.com with SMTP; 19 Sep 2011 16:01:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=uafVSlxrUzCl+sGKR7rBE1EQDpySimbyoDLqa3NwRfQ=; b=BadQoiHldmF1dBsmco1XroXeWFQKdZKxHpIp7+MuakOHF9TcJSKvoKllaehYzmspfJcFw+Gz2oROMJ/oHuNSz0me42GljkG9cgwDi2Lr1XXO6xEZBrvZzGvf0uCb5mdi;
Received: from mail-fx0-f44.google.com ([209.85.161.44]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from <kevin.gross@avanw.com>) id 1R5gHh-0000Ey-VH for avt@ietf.org; Mon, 19 Sep 2011 10:01:30 -0600
Received: by fxd18 with SMTP id 18so4485648fxd.31 for <avt@ietf.org>; Mon, 19 Sep 2011 09:01:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.39.154 with SMTP id g26mr5498023fae.7.1316448088654; Mon, 19 Sep 2011 09:01:28 -0700 (PDT)
Received: by 10.223.93.202 with HTTP; Mon, 19 Sep 2011 09:01:28 -0700 (PDT)
In-Reply-To: <0F41102E-7F7A-4D69-B22D-6BFC3215D6C0@apple.com>
References: <CALw1_Q0qK1WDc_KjEneOWrqr+jfVsqdwFYpF=ht-tS4SSNp8nQ@mail.gmail.com> <71C9EC0544D1F64D8B7D91EDCC6220200A2D0340@NABSREX027324.NAB.ORG> <alpine.BSF.2.00.1109141110001.25117@hsa.packetdesign.com> <CALw1_Q2L5z1bdVaENm7ky-epWjmxD326FLQ7THrObO_KMfdXfw@mail.gmail.com> <78481CCB-7A70-4BC4-91DC-A707301F22A5@apple.com> <CALw1_Q2VFe3d52ufVp2wSeNCHiwqgnhLh39dQTWYa52jWLaV+g@mail.gmail.com> <8EF3B729-407D-4A6F-9B5C-9E6833F2478B@apple.com> <CALw1_Q05fXDmTFapSaH1NRCsp2eWdemNus40gXsFwsx4HbR34Q@mail.gmail.com> <0F41102E-7F7A-4D69-B22D-6BFC3215D6C0@apple.com>
Date: Mon, 19 Sep 2011 10:01:28 -0600
Message-ID: <CALw1_Q0UD563WAES2bauEFa2+zr+qtwCs_=sX8hRED1VgPQTfw@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: avt@ietf.org
Content-Type: multipart/alternative; boundary="0015174781e6b0854f04ad4d749a"
X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.161.44 authed with kevin.gross@avanw.com}
Subject: Re: [AVTCORE] Leap seconds
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Sep 2011 15:59:08 -0000

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.

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

-- 
Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

v2.23.0 | Report a Bug | By Email