<html><head></head><body>Drag is an fluid dynamic term that suggests a meaning close to this... flow rate dependent friction.<br clear="none">
<br clear="none">
But what you really want to suggest is a flow rate dependent *delay* that people are familiar with quantifying.<br clear="none">
<br clear="none">
Fq_codel limits the delay as flow rate increases and is fair.<br clear="none">
<br clear="none">
The max buffer limits delay due to Little's lemma also.<br clear="none">
<br clear="none">
The actual delay limit in practice is what one measures in most cases. Codel is just softer than the hard limit of a small buffer.<br clear="none">
<br clear="none">
So there are two qualitative measures - delay limit in units of milliseconds and softness or stiffness in units of milliseconds per queue depth I'd guess. Softness gives the recovery rate after a burst.<br clear="none">
<br clear="none">
You should divide delay limit by elephant packet size in milliseconds. Based on channel rate.<br clear="none">
<br clear="none">
I'd think the scaled delay limit should<br clear="none"><br clear="none"><div class="gmail_quote">On Mar 20, 2015, "Bill Ver Steeg (versteb)" <versteb@cisco.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k10mail">I was kidding about "sucks-less", and forgot the smiley in my initial note.<br clear="none"><br clear="none">We do need a metric with an end-user-friendly name, though. Most people understand "lag", and understand that lower numbers are better. You could probably explain "lag-while-loaded" to most users (particularly people who care, like gamers) in a manner that got the point across.<br clear="none"><br clear="none">Bvs<br clear="none"><br clear="none"><br clear="none">-----Original Message-----<br clear="none">From: Jonathan Morton [mailto:chromatix99@gmail.com] <br clear="none">Sent: Friday, March 20, 2015 4:26 PM<br clear="none">To: Bill Ver Steeg (versteb)<br clear="none">Cc: Rémi Cardona; bloat; cerowrt-devel@lists.bufferbloat.net<br clear="none">Subject: Re: [Bloat] marketing #102 - giving netperf-wrapper a better name?<br clear="none"><br clear="none"><br clear="none"></pre><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">On 20 Mar, 2015, at 22:08, Bill Ver Steeg (versteb) <versteb@cisco.com> wrote:<br clear="none"><br clear="none">We should call the metric "sucks-less". As in "Box A sucks less than Box B", or "Box C scored a 17 on the sucks less test".</blockquote><br clear="none">I suspect real marketing drones would get nervous at a negative-sounding name.<br clear="none"><br clear="none">My idea - which I’ve floated in the past, more than once - is that the metric should be “responsiveness”, measured in Hertz. The baseline standard would be 10Hz, corresponding to a dumb 100ms buffer. Get down into the single-digit millisecond range, as fq_codel does, and the Responsiveness goes up above 100Hz, approaching 1000Hz.<br clear="none"><br clear="none">Crucially, that’s a positive sort of term, as well as trending towards bigger numbers with actual improvements in performance, and is thus more potentially marketable.<br clear="none"><br clear="none">- Jonathan Morton<br clear="none"><br clear="none"><hr><br clear="none">Cerowrt-devel mailing list<br clear="none">Cerowrt-devel@lists.bufferbloat.net<br clear="none"><a shape="rect" href="https://lists.bufferbloat.net/listinfo/cerowrt-devel">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br clear="none"></blockquote></div><br clear="none">-- Sent with <b><a shape="rect" href="https://play.google.com/store/apps/details?id=com.onegravity.k10.pro2">K-@ Mail</a></b> - the evolution of emailing.</body></html>