From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx11.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by huchra.bufferbloat.net (Postfix) with ESMTPS id CFDDF20111B for ; Fri, 29 Nov 2013 00:45:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,796,1378882800"; d="asc'?scan'208";a="80838122" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 29 Nov 2013 00:45:07 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.244]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Fri, 29 Nov 2013 00:45:07 -0800 From: "Eggert, Lars" To: =?iso-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= Subject: Re: One-way delay measurement for netperf-wrapper Thread-Topic: One-way delay measurement for netperf-wrapper Thread-Index: AQHO7Grz4tgcis7S6UabctRViyvmZJo8a9+A Date: Fri, 29 Nov 2013 08:45:06 +0000 Message-ID: References: <87zjoojr5u.fsf@toke.dk> In-Reply-To: <87zjoojr5u.fsf@toke.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_5E6C2855-B9A4-49C4-BA6D-8D6CD0C9A455"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 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 08:45:24 -0000 --Apple-Mail=_5E6C2855-B9A4-49C4-BA6D-8D6CD0C9A455 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On 2013-11-28, at 19:51, Toke H=F8iland-J=F8rgensen = wrote: > So I've been thinking about adding one-way delay measurement to > netperf-wrapper, but thought I'd solicit some input on how best to do > that. 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. If I remember correctly, the wrapper runs various netperf flows to = generate load, and in parallel runs a ping session in order to measure = latency. That works fine if all these flows go through all the same bottlenecks, = but when they don't (because the switch does something funky for ICMP, = etc.) it fails. It also doesn't account for stack-induced latencies. 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. (Yes, you wouldn't want/need to do this for each byte, I'm just speaking = conceptually.) 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. I think that Stas' thrulay tool did measure latencies in this way, but = it has accumulated some serious bitrot. Lars --Apple-Mail=_5E6C2855-B9A4-49C4-BA6D-8D6CD0C9A455 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUphUEdZcnpRveo1xAQJrQQP/Q2izGyrbVYTB1U4sfF5etm+NiVEjK/n9 hJorV9WYPSohksIb7QD2IggoaRdi1rAQKch0vpp4fTCocCzLHr3X3txhw6PhLLrQ 3m5Ku7thA6/J7lsztzx0x0b4GGVvsvuzEYlRVD85yPwMfp2pxEPaCgdG7ET+7cRF JAWTDs+sAUg= =oT+4 -----END PGP SIGNATURE----- --Apple-Mail=_5E6C2855-B9A4-49C4-BA6D-8D6CD0C9A455--