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

[d@taht.net (Dave Täht)]

Jonathan Morton <chromatix99@gmail.com> writes:

> On 20 Mar, 2011, at 10:33 pm, grenville armitage wrote:
>
> Customers won't be asking for "more Hertz" - or at least, none that
> have any sense.  They'll be asking for "more smoothness" for their
> video streams, or "more responsiveness" for their online games.  They
> already ask for "more bandwidth", not "more megabits per second".

I think despite your quest for a marketing number, that also reporting
actual RTT would be helpful (and horrifying, as I just got a .02HZ
rating on the still ongoing test...). 

I still can't claim to fully understand what this test is measuring.

Scenario 8: 2 uploads, 1 downloads... 4743 KiB/s up, 3422 KiB/s down, 0.02 Hz smoothness
Scenario 9: 3 uploads, 0 downloads... 7558 KiB/s up, 1.39 Hz smoothness
Scenario 10: 0 uploads, 4 downloads... 6719 KiB/s down, 2.08 Hz smoothness
Scenario 11: 1 uploads, 3 downloads... 4372 KiB/s up, 4067 KiB/s down, 1.30 Hz smoothness

The interesting outlier thus far is 8... I'm tempted to stop the test
now and recompile for testing 3 u/l 3 d/l first....

Even better, we could use a different name for your usage of hz or
smoothness here. Mortons?

(There, I named it for you. You cannot be accused of ego for using this
 new unit now. Enjoy. )

> Hertz makes sense as a unit because, when talking about latency or
> transmission delays, shorter times are better, but people understand
> "bigger is better" much more easily.  Hard drives used to measure
> their seek times in milliseconds too, but now they are measured in
> IOPS instead (a trend mostly associated with SSDs, which have IOPS
> numbers several orders of magnitude better than mechanical drives).
>
> Let me manually translate that for you, though.  That Responsiveness
> rating of 2Hz means that the practical RTT went above 334ms - and this
> on a switched Fast Ethernet being driven by good-quality 1996-vintage
> hardware on one side and a cheap nettop on the other.  It actually
> reflects not pure latency as 'ping' would have measured it, but a
> packet loss and the time required to recover from it.

Your explanation here is good. Perhaps it could be an automated textual
description. 

> And the "smoothness" rating actually contrived to be *worse*, at
> somewhere north of 500ms.  At Fast Ethernet speeds, that implies
> megabytes of buffering, on what really is a very old computer.

Txqueuelen = 1000 = ~1.5Mbyte (and I'm struggling with using consistent
decimal or base 2 units this month) Mibibyte?

Normal dma tx ring size ranges from 64 to 512, can be seen sometimes
with ethtool -g device

> It's a clear sign of something very broken in the network stack,
> especially as I get broadly similar results (with much higher
> throughput numbers) when I run the same test on GigE hardware with
> much more powerful computers (which can actually saturate GigE).
>
> You really don't want to see what I got on my 3G test runs.  I got
> 0.09 Hz from a single flow, and these tests run all the way up to 32
> flows.  I think the modem switched down into GPRS mode for a few
> minutes as well, even though there was no obvious change in
> propagation conditions.
>

-- 
Dave Taht
http://nex-6.taht.net