Re: [Bloat] Measuring latency-under-load consistently

[Rick Jones <rick.jones2@hp.com>]

On Sat, 2011-03-12 at 02:00 +0200, Jonathan Morton wrote:
> I'm currently resurrecting my socket-programming skills (last used
>  almost 10 years ago when IPv6 really *was* experimental) in the hope
>  of making a usable latency-under-load tester.  This could be run in
>  server-mode on one host, and then as a client on another host could be
>  pointed at the server, followed by several minutes of churning and
>  some nice round numbers.
> 
> It would need to make multiple TCP connections simultaneously, one of
>  which would be used to measure latency (using NODELAY marked sockets),
>  and one or more others used to load the network and measure goodput. 
>  It would automatically determine how long to run in order to get a
>  reliable result that can't easily be challenged by (eg.) an ISP.

Why would it require multiple TCP connections?  Only if none of the
connections have data flowing in the other direction, and your latency
measuring one would need that anyway. 

Also, while NODELAY (TCP_NODELAY I presume) might be interesting with
something that tried to have multiple, sub-MSS transactions in flight at
one time, it won't change anything about how the packets flow on the
network - TCP_NODELAY has no effect beyond the TCP code running the
connection associated with the socket for that connection.

If you only ever have one transaction outstanding at a time, regardless
of size, if TCP_NODELAY improves the latency, it means the TCP stack is
broken wrt how to interpret the Nagle algorithm - likely as not it is
trying to apply it segment by segment rather than by user send by user
send.

> The output metrics would be:
> 
> 1) Average goodput for uplink and downlink, for single flows and
>  multiple flows, in binary megabytes per second.  Just for laughs, I
>  might also add the equivalent gigabytes-per-month figures.
> 
> 2) Maximum latency (in the parallel "interactive" flow) under load,
>  expressed in Hz rather than milliseconds.  This gives a number that
>  gets bigger for better performance, which is much easier for laymen to
>  understand.
> 
> 3) Flow smoothness, measured as the maximum time between sequential
>  received data for any continuous flow, also expressed in Hz.  This is
>  an important metric for video and radio streaming, and one which CUBIC
>  will probably do extremely badly at if there are large buffers in the
>  path (without AQM or Blackpool).
> 
> Any thoughts on this idea?

You may be able to get most of what you want with a top-of-trunk netperf
"burst mode" TCP_RR test. It isn't quite an exact match though.

The idea is to ./configure netperf for burst mode and histogram, and
probably the "omni" tests to get the more complete statistics on RTT
latency, then run a burst mode TCP_RR test - if doing "upload" then with
a large request size and a single byte response size.  If doing
"download" then with a single byte request size and a large response
size.

If you want to hear more, contact me off-list and I can wax philosophic
on it.

rick jones

>  - Jonathan
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat