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