IETF Logo Mail Archive

Re: [AVTCORE] Leap seconds

Qin Wu <bill.wu@huawei.com> Wed, 21 September 2011 02:39 UTC

Return-Path: <bill.wu@huawei.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 4269E21F8BE8 for <avt@ietfa.amsl.com>; Tue, 20 Sep 2011 19:39:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.351
X-Spam-Level:
X-Spam-Status: No, score=-5.351 tagged_above=-999 required=5 tests=[AWL=1.247, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 MOV+757AtHIx for <avt@ietfa.amsl.com>; Tue, 20 Sep 2011 19:39:36 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0233221F8BDC for <avt@ietf.org>; Tue, 20 Sep 2011 19:39:36 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRU008YJQ60NU@szxga03-in.huawei.com> for avt@ietf.org; Wed, 21 Sep 2011 10:42:00 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRU005E6Q5PYA@szxga03-in.huawei.com> for avt@ietf.org; Wed, 21 Sep 2011 10:42:00 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEB65663; Wed, 21 Sep 2011 10:41:59 +0800
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 21 Sep 2011 10:41:53 +0800
Received: from w53375q (10.138.41.130) by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 21 Sep 2011 10:41:57 +0800
Date: Wed, 21 Sep 2011 10:41:57 +0800
From: Qin Wu <bill.wu@huawei.com>
X-Originating-IP: [10.138.41.130]
To: Kevin Gross <kevin.gross@avanw.com>, Colin Perkins <csp@csperkins.org>
Message-id: <11B21ADB2984461D8045E2F7EA8D659C@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
Content-type: multipart/alternative; boundary="Boundary_(ID_LtVC+wUzqwlrs6Fb+5YZQQ)"
X-Priority: 3
X-MSMail-priority: Normal
X-CFilter-Loop: Reflected
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> <CALw1_Q0UD563WAES2bauEFa2+zr+qtwCs_=sX8hRED1VgPQTfw@mail.gmail.com> <CAJNg7VJqxQ9QFV7dgBbH8PVQVt88kAsX-xgr9XAf4ZO4-_x2kw@mail.gmail.com> <CALw1_Q2jGj_pHowfzgxMSBKXdEU99k=ST217PCBYtznRjBsvfA@mail.gmail.com> <4E78487D.1030602@ericsson.com> <CALw1_Q0urojdegAdsJ7L7bT=0680RN-0pk1g7J4zhP-aK3M5ew@mail.gmail.com> <6A72C4E9-B429-4B97-B4AA-98E420DF4C94@csperkins.org> <CALw1_Q1hb3mynU9J-PmdBH33RT2tWYt6Ba6he7Tojog-b-3GaQ@mail.gmail.com>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, avt@ietf.org, Marshall Eubanks <marshall.eubanks@gmail.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: Wed, 21 Sep 2011 02:39:37 -0000

I am not sure Precision Time protocol defined in IEEE1588 is subject to leap seconds, but I am aware GPS and TAI are two timescales that don't follow leap seconds.
So one solution to overcome  leap seconds is to use GPS as clocksource and convert GPS time to NTP timestamp. Otherwise manually updated and maintained leap seconds table
will be used to correct UTC time and NTP time when leap seconds occurs.

Also I am aware that there is long debate in ITU-T Studay Group 7 regarding abolishing leap seconds. It was said that in 2017, the leap seconds will not be used. UTC will be continuous 
timescale. so shall we really need to be worried about this issue?

Regards!
-Qin

  ----- Original Message ----- 
  From: Kevin Gross 
  To: Colin Perkins 
  Cc: Magnus Westerlund ; avt@ietf.org ; Marshall Eubanks 
  Sent: Wednesday, September 21, 2011 7:17 AM
  Subject: Re: [AVTCORE] Leap seconds


  Well, that would fix things. By my reading, RFC 3550 is not clear on this however. I'm not sure trying to figure out the original intent of the RFC will help us resolve things because nowhere in the text do I see any indications that the RFC authors gave consideration to the NTP leap second issue.


  The RFC does say "Wallclock time (absolute date and time) is represented using the timestamp format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC on 1 January 1900." (emphasis on timestamp format mine) Since it doesn't say anything about leap seconds, you could interpret it as Dave Singer and Colin Perkins have to mean actual seconds elapsed.


  But a couple sentences later there's, "Running NTP may be useful for synchronizing streams transmitted from separate hosts." Again, no mention of leap-seconds but here, since we're talking about actual NTP (as opposed to "NTP timestamp format"), wouldn't you be inclined to assume that leap seconds are included in timestamps in this suggested implementation?


  I have already determined that TAI time is best for my application. If anyone knows of any existing signaling mechanism I can use to communicate this to receivers (e.g. specific SDP a= records), I would welcome suggestions.


  Kevin Gross

  On Tue, Sep 20, 2011 at 4:21 PM, Colin Perkins <csp@csperkins.org> 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





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


  _______________________________________________
  Audio/Video Transport Core Maintenance
  avt@ietf.org
  https://www.ietf.org/mailman/listinfo/avt

v2.23.0 | Report a Bug | By Email