Re: [Bloat] Progress with latency-under-load tool

[Jonathan Morton <chromatix99@gmail.com>]

Unfortunately that patch will not work - it completely breaks part of the on-wire protocol. It is much better to simply convert the final results for an auxiliary display. 

At the moment I am working to prove that high smoothness and responsiveness can actually be measured, which requires first setting up a network which can genuinely achieve it. I was surprised to find that pure Ethernet was not by default sufficient, though it is easily explainable. 

I should also point out that I have very strong reasons for providing the measurements in non-traditional units by default. I'm measuring characteristics as they matter to applications and users, who measure things in bytes and frames per second, not bits and milliseconds. It is also much easier to get nontechnical people (who tend to be in charge of budgets) to respond to bigger-is-better numbers. 

The key to knowledge is not to rely on others to teach you it. 

On 23 Mar 2011, at 12:33, Otto Solares Cabrera <solca@guug.org> wrote:

> On Sun, Mar 20, 2011 at 12:45:10PM +0200, Jonathan Morton wrote:
>> Attached is the initial version of the loadlatency tool.  I'm getting some rather interesting results from it already, although it does take a very long time to run.
>> 
>> It works under Linux, Cygwin and MacOS X on both little- and big-endian machines (and between machines of different byte-sexes), and therefore it should also work under FreeBSD and other UNIXes.  I haven't yet tried compiling it for iOS or Android.
>> 
>> It produces useful results even when one of the machines is rather old and slow, despite using a proper PRNG for traffic generation.  My ancient Pentium-MMX proved capable of generating at least 4.4 MB/s of traffic steadily, and probably produces spikes of even greater bandwidth.  Anything of Y2K vintage or newer should be able to saturate it's network with this.
>> 
>> There are four measures produced:  Upload Capacity, Download Capacity, Link Responsiveness and Flow Smoothness.  All of these are reported in "bigger is better" units to help deal with Layers 8 and 9.
> 
> Hello Jonathan,
> 
> Excellent tool! hopefully with more testing we can validate it's
> results and improve it as testing all those scenarios seems the
> correct path to understand bufferbloat and latency in our networks.
> 
> Sadly it's very difficult for a netadmin like me to follow your "units"
> as the world have been standarized on bits per second in base10 or
> decimal as opposed to the bytes per second in base2 or binary as
> reported by this tool, "smoothness" too is a very radical unit to
> measure latency which could be in milliseconds as the tool name implies.
> 
> Please don't take it as an offense but I cooked this small patch to
> address this problems in the case you want to change it or for others
> if they feel the need for more "normal" measuring units which in turn
> can lead to more people testing their networks with this tool.
> 
> It's a diff against nbd's git repository, it seems to work for me but
> honestly I have yet to figure out all the data it reports, hopefully
> I didn't b0rk it too much :)
> -
> Otto
> <loadlatency_units.patch>