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 5D5F121F228 for ; Fri, 29 Nov 2013 06:30:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,798,1378882800"; d="asc'?scan'208";a="80940200" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx11-out.netapp.com with ESMTP; 29 Nov 2013 06:30:32 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.244]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Fri, 29 Nov 2013 06:30:31 -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: AQHO7QOQ4tgcis7S6UabctRViyvmZJo8yy2A Date: Fri, 29 Nov 2013 14:30:31 +0000 Message-ID: <503FC4CA-967A-407A-9A93-97D61FE11566@netapp.com> References: <87zjoojr5u.fsf@toke.dk> <87mwknk0hw.fsf@toke.dk> <5392347C-BC88-4836-BB53-F48523210237@netapp.com> <87haavjr4m.fsf@toke.dk> In-Reply-To: <87haavjr4m.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=_2B13C520-EB01-432A-B99F-91173D5DEEE8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Midori Kato , "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 14:30:50 -0000 --Apple-Mail=_2B13C520-EB01-432A-B99F-91173D5DEEE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On 2013-11-29, at 14:04, Toke H=F8iland-J=F8rgensen = wrote: > Now, some possible issues with this: >=20 > - Are we measuring the right thing? This will measure the time it = takes > a message to get from the application level on one side to the > application level on another. There are a lot of things that could > impact this apart from queueing latency; the most obvious one is > packet loss and retransmissions which will give some spurious results > I suppose (?). Doing the measurement with UDP packets would alleviate > this, but then we're back to not being in-stream... right. I happen to be interested in that metric, but not everyone may = be. Some folks may only care about latencies added in the network, in = which case the TCP-timestamp-based approach might be better (if the = kernel can be convinced to generate timestamps with sufficient = resolution). You could also combine the two approaches. That way, you might be able = to account for sender, network and receiver latencies. > - As for point 3, not normalising the result and just outputting the > computed delay as-is means that the numbers will be meaningless > without very accurately synchronised clocks. On the other hand, not > processing the numbers before outputting them will allow people who > *do* have synchronised clocks to do something useful with them. > Perhaps a --assume-sync-clocks parameter? Yep. Or you could check for the accuracy of the NTP synchronization, as = suggested by Hal. > - Echoing back the delay measurements causes traffic which may or may > not be significant; I'm thinking mostly in terms of running > bidirectional measurements. Is that significant? A solution could be > for the receiver to hold on to all the measurements until the end of > the test and then send them back on the control connection. Depends on the measurement interval. I'm guessing it won't matter much = if you e.g. only timestamp once a millisecond or something. > - Is clock drift something to worry about over the timescales of these > tests? > https://www.usenix.org/legacy/events/iptps10/tech/slides/cohen.pdf > seems to suggest it shouldn't be, as long as the tests only run for = at > most a few minutes. Wouldn't think so. > So anyway, thoughts? Is the above something worth pursuing? I certainly would like this test. It may also be a good proposal for the = IPPM metric. Lars --Apple-Mail=_2B13C520-EB01-432A-B99F-91173D5DEEE8 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----- iQCVAwUBUpilBNZcnpRveo1xAQJMvQP7BGj1laMS9XBCG5yIYm3C1DXBJ89qyILZ EMiXD6gCGkmv0Y5dC/OtAkPSmwOHlqeWwE9RBP2ig8yxAbVL3l/A/AM/PyTTtEFP yCGDqZ6I9VJuTVh9IgX296OylJeUC1eMSmhNcwBQCLtM/4L73n2oZHJShiAoJVw1 KhPkyh/I8nM= =r2Jl -----END PGP SIGNATURE----- --Apple-Mail=_2B13C520-EB01-432A-B99F-91173D5DEEE8--