From: grenville armitage <garmitage@swin.edu.au>
To: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] Progress with latency-under-load tool
Date: Fri, 18 Mar 2011 10:38:00 +1100 [thread overview]
Message-ID: <4D829B58.1070601@swin.edu.au> (raw)
In-Reply-To: <0D59AD34-AA64-4376-BB8E-58C5D378F488@gmail.com>
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
next prev parent reply other threads:[~2011-03-17 23:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-16 2:31 Jonathan Morton
2011-03-16 17:12 ` Rick Jones
2011-03-17 23:38 ` grenville armitage [this message]
2011-03-19 17:44 ` Jonathan Morton
2011-03-20 10:45 ` Jonathan Morton
2011-03-20 20:33 ` grenville armitage
2011-03-20 20:53 ` Dave Täht
2011-03-20 21:52 ` Jonathan Morton
2011-03-20 22:32 ` Dave Täht
2011-03-20 22:47 ` Dave Täht
2011-03-20 22:52 ` Jonathan Morton
2011-03-20 22:55 ` Dave Täht
2011-03-20 23:42 ` Dave Täht
2011-03-20 21:50 ` [Bloat] Some results of the latency under load tool Dave Täht
2011-03-20 22:24 ` Jonathan Morton
[not found] ` <m3d3llgln8.fsf@yahoo.com>
2011-03-21 6:43 ` [Bloat] Progress with latency-under-load tool Jonathan Morton
2011-03-22 1:13 ` Kim Hawtin
2011-03-22 7:10 ` Jonathan Morton
2011-03-23 10:33 ` Otto Solares Cabrera
2011-03-23 11:26 ` Jonathan Morton
2011-03-23 19:27 ` Otto Solares
2011-03-23 20:40 ` Jonathan Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D829B58.1070601@swin.edu.au \
--to=garmitage@swin.edu.au \
--cc=bloat@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox