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 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
