[babel] Accuracy of timestamps for babel-rtt: userspace vs kernel timestamps
Baptiste Jonglez <baptiste.jonglez@imag.fr> Thu, 25 July 2019 16:52 UTC
Return-Path: <baptiste.jonglez@imag.fr>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21235120155 for <babel@ietfa.amsl.com>; Thu, 25 Jul 2019 09:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.119
X-Spam-Level:
X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 2MWEinAL7UG9 for <babel@ietfa.amsl.com>; Thu, 25 Jul 2019 09:52:21 -0700 (PDT)
Received: from zm-mta-out-1.u-ga.fr (zm-mta-out-1.u-ga.fr [152.77.200.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874CC12013E for <babel@ietf.org>; Thu, 25 Jul 2019 09:52:09 -0700 (PDT)
Received: from zm-mta-out.u-ga.fr (zm-mta-out.u-ga.fr [152.77.200.58]) by zm-mta-out-1.u-ga.fr (Postfix) with ESMTP id BE953A03C2; Thu, 25 Jul 2019 18:52:07 +0200 (CEST)
Received: from smtps.univ-grenoble-alpes.fr (smtps1.u-ga.fr [152.77.1.30]) by zm-mta-out.u-ga.fr (Postfix) with ESMTP id BA933E00AF; Thu, 25 Jul 2019 18:52:07 +0200 (CEST)
Received: from imag.fr (blaine.imag.fr [129.88.55.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jonglezb@univ-grenoble-alpes.fr) by smtps.univ-grenoble-alpes.fr (Postfix) with ESMTPSA id B82BA125EB7; Thu, 25 Jul 2019 18:52:07 +0200 (CEST)
Date: Thu, 25 Jul 2019 18:52:06 +0200
From: Baptiste Jonglez <baptiste.jonglez@imag.fr>
To: babel-users@lists.alioth.debian.org, babel@ietf.org
Message-ID: <20190725165206.m6xj4kjcfo42xmqb@imag.fr>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="fwi3f2lcpllsusts"
Content-Disposition: inline
User-Agent: NeoMutt/20170113 (1.7.2)
X-Greylist: Whitelist-UGA SMTP Authentifie (jonglezb@univ-grenoble-alpes.fr) via smtps-465 ACL (112)
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/T_qUuzPYFdwpsNL0SHXm5uqrNhc>
Subject: [babel] Accuracy of timestamps for babel-rtt: userspace vs kernel timestamps
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2019 16:52:23 -0000
Hello, A recent discussion with Dave convinced me to start looking at whether very short RTTs make any sense in Babel, and whether they could be used to infer link speed. If only to settle theses questions for good. Since the related subject of nanosecond-resolution timestamps was brought up by Toke at the IETF session yesterday, I made a quick test with kernel timestamps today. I'll talk about the implementation and shortcomings of using kernel timestamps below, but here are some rough timing results. I just used a veth pair on my laptop (4.17 kernel) with a babeld on each side of the pair, and didn't do any serious statistics. - regular babeld: average measured RTT ~320 µs (quite variable) - babeld with kernel RX timestamps: average measured RTT ~120 µs (quite variable) - ping through the same veth pair (link-local IPv6, 1000 packets): average 105 µs, minimum 16 µs The observant reader will notice that the current resolution (1 µs) is more than enough in that case. Also, using kernel timestamps improves accuracy by about 100 µs on each host, a somewhat significant improvement. Now, regarding the implementation of kernel timestamps in babeld, my test code is here: https://github.com/jonglezb/babeld/commit/56756a8cbe9a0b8a168c78873dd77e48e5770278 Thank you Dave for your first draft of this code, I borrowed a bit from it ;) As explained in the commit message, it suffers from a number of issues that would need some serious work before it's really usable: - kernel timestamps use the realtime clock, and it's not configurable. This is really annoying because babeld uses the monotonic clock (for good reasons). Using kernel timestamps forces us to fall back to the realtime clock elsewhere in babeld, and it would require some work to do it cleanly. - kernel timestamps are only used for received packets. The sending side (timestamp in Hello) still uses userspace timestamps, with the ensuing accuracy issue. It does not seem possible to tell the kernel to embed a timestamp at a specified location in a packet just before sending it, unless maybe playing with eBPF. Takeaway: at least on Linux, I don't see a use-case for nanosecond resolution timestamps. If somebody ever writes an implementation of Babel for specialized hardware and runs a datacenter with ultra-low-latency network equipments, it could possibly still make sense. -- Baptiste Jonglez PhD student Univ. Grenoble Alpes <https://www.univ-grenoble-alpes.fr/> LIG lab <https://www.liglab.fr/> Drakkar team <http://drakkar.imag.fr/> | Polaris team at INRIA <https://team.inria.fr/polaris/>
- [babel] Accuracy of timestamps for babel-rtt: use… Baptiste Jonglez
- Re: [babel] Accuracy of timestamps for babel-rtt:… Juliusz Chroboczek
- Re: [babel] Accuracy of timestamps for babel-rtt:… Dave Taht