From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-23-ewr.dyndns.com (mxout-122-ewr.mailhop.org [216.146.33.122]) by lists.bufferbloat.net (Postfix) with ESMTP id 5B23A2E018E for ; Thu, 17 Mar 2011 16:38:10 -0700 (PDT) Received: from scan-21-ewr.mailhop.org (scan-21-ewr.local [10.0.141.243]) by mail-23-ewr.dyndns.com (Postfix) with ESMTP id 500C1409F9 for ; Thu, 17 Mar 2011 23:38:09 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 136.186.1.32 Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) by mail-23-ewr.dyndns.com (Postfix) with ESMTP id 96FC0407F2 for ; Thu, 17 Mar 2011 23:38:04 +0000 (UTC) Received: from [10.1.1.54] (garmitage4.caia.swin.edu.au [136.186.229.45]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id p2HNc0ld019463 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 18 Mar 2011 10:38:02 +1100 Message-ID: <4D829B58.1070601@swin.edu.au> Date: Fri, 18 Mar 2011 10:38:00 +1100 From: grenville armitage User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: <0D59AD34-AA64-4376-BB8E-58C5D378F488@gmail.com> In-Reply-To: <0D59AD34-AA64-4376-BB8E-58C5D378F488@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Bloat] Progress with latency-under-load tool X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 23:38:10 -0000 So, this is probably tangential to what the latency-under-load tool is aiming to achieve, but we have a tool that can be used to measure RTT between two points (e.g. either side of an 802.11 link) using tcpdump on consumer-grade PCs and no active probing (ala ping). http://caia.swin.edu.au/tools/spp/ Our SPP tool takes two tcpdump files (captured at two points in the network) and seeks out 'packet pairs' observed passing both points. From these, it can calculate the RTT between the two measurement points. So far, pretty boring and standard. But it can be useful for people who: - only have consumer-grade PCs with only modestly synchronised clocks at the measurement points (i.e. that don't drift much in an RTT, and are within a few tens of seconds of each other in absolute time) - don't want to add active probe traffic to the network path being tested (e.g. measuring the RTT as experienced by actual application flows over 802.11 wireless links without additional ICMP probing) - Have asymmetric traffic flow between the two points (e.g. an online FPS game sending 50ms updates in one direction and 10-40ms updates in the other -- SPP uses a subset of the two-way traffic to calculate RTT between the measurement points) Anyway, thought this might be of interested for anyone looking to measure the latency across their home networking gear under load (assuming you can tcpdump capture packets at two points either side of the box whose buffers you're intrigued by). cheers, gja