Re: [ntpwg] [ntp:questions] Idea to improve ntpd accuracy

Martin Burnicki <martin.burnicki@meinberg.de> Fri, 26 February 2016 13:42 UTC

Return-Path: <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>
X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com
Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9C81B2B75 for <ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com>; Fri, 26 Feb 2016 05:42:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.796
X-Spam-Level:
X-Spam-Status: No, score=-6.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, T_DKIM_INVALID=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Cpk7LNZHjBP for <ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com>; Fri, 26 Feb 2016 05:42:56 -0800 (PST)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 9244E1B2B71 for <ntp-archives-ahFae6za@lists.ietf.org>; Fri, 26 Feb 2016 05:42:56 -0800 (PST)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 84F6F86DBA5 for <ntp-archives-ahFae6za@lists.ietf.org>; Fri, 26 Feb 2016 13:42:56 +0000 (UTC)
X-Original-To: ntpwg@lists.ntp.org
Delivered-To: ntpwg@lists.ntp.org
Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 1215C86DABD; Fri, 26 Feb 2016 13:22:03 +0000 (UTC)
Received: from server1a.meinberg.de ([176.9.44.212]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from <martin.burnicki@meinberg.de>) id 1aZILC-0009K9-DE; Fri, 26 Feb 2016 13:22:03 +0000
X-DKIM: Sendmail DKIM Filter v2.8.2 server1a.meinberg.de 7F49D71C0093
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=meinberg.de; s=mail201101; t=1456492911; bh=VAEcZHREzdahVyAgorXNRaVyMTr4n98NUh9K052jpGQ=; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=GUMdZQpOmE8wrdFlHiljiaQal4UtiZj1Mz/ehY1gObRXWY5I4Ph8f5bFgd2BXqqhj ilYV0ZFF2/2mqOICeGo9+V4D2ILk0lLnxy+zTgytpBx1S35Qp9a8Iwb/dr5jSY/lnV ZNvER9Fa55/4u5kNdyGDNRr1XTl82OLomjTmgRRw=
To: Tal Mizrahi <talmi@marvell.com>, "mayer@ntp.org" <mayer@ntp.org>, Weber <wsdl@osengr.org>
References: <56CF7783.3010804@osengr.org> <56CFC1FF.2060408@ntp.org> <56CFC6A2.4010000@osengr.org> <56CFCB89.4010704@ntp.org> <e8a82cbb01c94da7b43d60b18afa2b8a@IL-EXCH01.marvell.com>
From: Martin Burnicki <martin.burnicki@meinberg.de>
Message-ID: <56D0516B.20207@meinberg.de>
Date: Fri, 26 Feb 2016 14:21:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40
MIME-Version: 1.0
In-Reply-To: <e8a82cbb01c94da7b43d60b18afa2b8a@IL-EXCH01.marvell.com>
X-Virus-Scanned: clamav-milter 0.98.7 at server1a
X-Virus-Status: Clean
X-SA-Exim-Connect-IP: 176.9.44.212
X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org, questions@lists.ntp.org
X-SA-Exim-Mail-From: martin.burnicki@meinberg.de
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on mail1.ntp.org)
Subject: Re: [ntpwg] [ntp:questions] Idea to improve ntpd accuracy
X-BeenThere: ntpwg@lists.ntp.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: IETF Working Group for Network Time Protocol <ntpwg.lists.ntp.org>
List-Unsubscribe: <http://lists.ntp.org/options/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=unsubscribe>
List-Archive: <http://lists.ntp.org/pipermail/ntpwg/>
List-Post: <mailto:ntpwg@lists.ntp.org>
List-Help: <mailto:ntpwg-request@lists.ntp.org?subject=help>
List-Subscribe: <http://lists.ntp.org/listinfo/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=subscribe>
Cc: "'ntpwg@lists.ntp.org'" <ntpwg@lists.ntp.org>, "questions@lists.ntp.org" <questions@lists.ntp.org>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org
Sender: ntpwg <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>

Tal Mizrahi wrote:
> Hi,
> 
> I believe NTP hardware timestamping is certainly a very interesting direction.
> It is certainly worth taking a look at https://datatracker.ietf.org/doc/draft-ietf-ntp-checksum-trailer
> 
> I wonder what is the level of accuracy you are looking for.
> 
> The factor that affects the NTP client's accuracy more than anything else is the distance (latency) between the NTP server and the NTP client, which is roughly proportional to the delay variation.
> If the NTP server and the NTP client are on the same LAN, I would estimate that you can achieve an accuracy on the order of tens of microseconds with software timestamping. In this case hardware timestamping may improve the accuracy.
> If the latency between the NTP server and client is tens of *milliseconds*, then hardware timestamping will hardly affect the accuracy.
> 
> Please note that even if you have hardware-based timestamping, using a hardware clock in the NIC, you still need to synchronize the hardware clock with the system clock (for example, this can be done using phc2sys). This procedure will typically add some inaccuracy to the overall calculation...

And the remaining problem will be that there are switches and routers
which do hardware timestamping on PTP packets to measure the latency of
forwarded packets, but (AFAIK) there are no such devices which can do
this with NTP packets.

So even if both end nodes support hardware timestamping, the result will
unfortunately still be worse than with PTP.

>>>>> What if the poll response packet contained a flag or indication of
>>>>> some sort which means "this is an approximate transmit timestamp".
>>>>> That packet would then be immediately followed by a second response
>>>>> packet with a more accurate transmit time. The second packet could
>>>>> be otherwise identical to the first, or it could be a new flavor of
>>>>> packet that contained only the transmit time (that would save on network
>> bandwidth).
>>>>>
> 
> Sounds a bit like interleave mode, right (a bit similar to PTP two-step clocks)?

But the problem is still that (again, AFAIK) NTP interleave mode works
only in broadcast mode.

In broadcast mode ntpd only tries to measure the packet delay when the
association is first created, but the network route etc. can change at
any time, so IMO interleave mode provides only limited benefit.

Please let me know if I'm missing something.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki@meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg