Linux console tool to evaluate round trip latency within a TCP/UDP session?
Wireshark might do this, but I am pretty sure I saw a black and white console example where the tool evaluated the sub-second timings between when a packet leaves and it's response comes back. Probably by setting a series of filters for interesting traffic.
A couple of examples come to mind:
1) evaluating dns queries: when people complain their 'internet is down', it isn't because they are disconnected, it can be due to dns queries timing out. Or being slow. And in some diagnostic scenarios, it is interesting to see what queries are slow and what queries are fast, and what the difference is.
2) Web browsing: what are the timings of the setup of the three way tcp handshake? This gets a relative idea of latency to the server. Then what is the timing of requesting an http header and it's response... which provides an idea of latency further up the stack.
Then I suppose, an open question, what do people use to measure these sorts of things?
6 comments
[ 2.9 ms ] story [ 63.1 ms ] threadI think I am thinking more along the lines of http://www.tcptrace.org. I just came across it. I am not sure if that is the one about which I am thinking.
tcptrace takes the output from these collectors and provides some time based statistics. but from what I've read, xplot is required to get a timeline of the individual packet interactions. I am in the process of loading it up to read the man page and give it a try.
I still don't think tcptrace was the tool I originally saw, but will check it out.
http://prefetch.net/blog/index.php/2006/04/17/debugging-tcp-... provides some sample output... but not the timeline I had in mind.
There's nothing simple about tcpdump/wireshark.
Wireshark does deltas for you if you want and can even calculate the RTT at every point in time during the lifetime of a TCP flow. Wireshark is fucking awesome and I'm sad you would say "simply provides..." :'(
But if what you want is just to know the RTT for a 3 way handshake against a remote endpoint, try something like gotcping: https://github.com/pjperez/gotcping/releases
tracetcp (and variants) is not what you want, because it calculates the time it takes for you to get a "TTL expired in transit" ICMP back except on the last hop. Gotcping and other avoid wasting your time by just testing the final endpoint.