From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [144.76.141.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 59BD021F22D for ; Fri, 29 Nov 2013 01:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at example.com Sender: toke@toke.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1385718095; bh=+Z/2GJELxYsHfoulPtpbHs7jNKNIGin/49bzIVIjdcE=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=krM6BxUL+kyDyhIoCapA6WObCcIUBGKnHmsW+rS7dBB8/fO1OOeEAmxWFIO6sfI0R R9MeQx/LNWVqbxnThCJsu97xIXCJ7kt62M0JDgomAoIbVWOXC0ZscBGS8kqP2STqSU 13qfn0TVE3BTFVZwqJiYgZ1Z+EH6Yg5sITJRWfxI= Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id DC52BDE3E; Fri, 29 Nov 2013 09:42:20 +0000 (GMT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: "Eggert\, Lars" Subject: Re: One-way delay measurement for netperf-wrapper References: <87zjoojr5u.fsf@toke.dk> Date: Fri, 29 Nov 2013 09:42:19 +0000 In-Reply-To: (Lars Eggert's message of "Fri, 29 Nov 2013 08:45:06 +0000") Message-ID: <87mwknk0hw.fsf@toke.dk> Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Cc: "bloat-devel@lists.bufferbloat.net" X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 09:42:15 -0000 --=-=-= Content-Type: text/plain "Eggert, Lars" writes: > that would be a great addition. But I think it will require some > fundamental change to the wrapper (actually , probably to netperf.) Or > at least a solution a complete solution would. Yeah, I was thinking of putting the functionality into netperf. > I'd really like to see some measurement tool (netperf, flowgrind, > etc.) grow support for measuring latencies based on the actual > load-generating data flow. Ideally and assuming fully sync'ed clocks, > I'd like to timestamp each byte of a TCP stream when an app does > write(), and I'd like to timestamp it again when the receiving app > read()s it. The difference between the two timestamps is the latency > that byte saw end-to-end. Well, what the LINCS people have done (the link in my previous mail) is basically this: Sniff TCP packets that have timestamps on them (i.e. with the TCP timestamp option enabled), and compute the delta between the timestamps as a latency measure. Now this only gives an absolute latency measure if the clocks are synchronised; however, if we're interested in measuring queueing latency, i.e. induced *extra* latency, this can be calculated as (latency - min-latency) where min-latency is the minimum observed latency throughout the lifetime of the connection (this is the same mechanism LEDBAT uses, btw). In this case the unknown clock discrepancy cancels out (assuming no clock drift over the course of the measurement, although there's presumably a way to compensate for that, but I haven't been able to get hold of the actual paper even though it's references in several others...). The LINCS paper indicates that the estimates of queueing latency from this method can be fairly accurate. So I guess my question is firstly whether this way of measuring OWD would be worthwhile, and secondly if anyone has any idea whether it will be possible to implement (it would require access to the raw timestamp values of the TCP data packets). Putting timestamps into the TCP stream and reading them out at the other end might work; but is there a way to force each timestamp to be in a separate packet? > That measurement would include the stack/driver latencies which you > don't currently capture with a parallel ping. For datacenter scenarios > with very low RTTs, these sources of latency begin to matter. Yeah, I'm aware of that issue and fixing it was one of the reasons I wanted to do this... :) > I think that Stas' thrulay tool did measure latencies in this way, but > it has accumulated some serious bitrot. Do you know how that worked more specifically and/or do you have a link to the source code? -Toke --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJSmGF7AAoJEENeEGz1+utP8xYIAKuppoN8K8ouxazW7O4za2ak nK3yDd9YMEM8aG36dQfjkPw0QAWAOl6MdHnRFXJ4xY7pi6oioOW7kp/wihGy9R38 QtbAEOxyZB+/GUpZhBqLb2FMqsiYdD6GI4v8uGG5WYP/zkOyJ17EtSZI1T9syn58 4YNgeX7R+WT4J+we5y9/BPiy0gefUL9CdR+dCN52bKG2KahwggOVr4ABlRO6nN+g nKhmAGKnVk+mab41Nm6VdlwRlpETh2+FQE+b2810pXnNEQ/eIDhbz/22ur8p25Ef kJppMB9HZ+JEPvm17Fg4kQpnMQY8SijSBmd0HafMXZnuCBQa6QM3KQ2GjyuRnOo= =OzPP -----END PGP SIGNATURE----- --=-=-=--