[Bloat] Progress with latency-under-load tool

[grenville armitage]

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