From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp89.iad3a.emailsrvr.com (smtp89.iad3a.emailsrvr.com [173.203.187.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id ADF7021F417 for ; Fri, 20 Mar 2015 17:19:50 -0700 (PDT) Received: from smtp12.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp12.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 41FF53802C5; Fri, 20 Mar 2015 20:19:49 -0400 (EDT) Received: by smtp12.relay.iad3a.emailsrvr.com (Authenticated sender: dpreed-AT-reed.com) with ESMTPSA id 7D2A23802E7; Fri, 20 Mar 2015 20:19:48 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from [100.79.243.24] (85.sub-70-192-7.myvzw.com [70.192.7.85]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Sat, 21 Mar 2015 00:19:49 GMT User-Agent: K-@ Mail for Android X-Priority: 3 In-Reply-To: References: <55028CB6.80101@gentoo.org> <2584B47E-BBE6-491E-BE44-8BA4E5075085@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----WXENMZTC29VGSNNCH3YF6KRTFBO1FJ" Content-Transfer-Encoding: 7bit From: "David P. Reed" Date: Fri, 20 Mar 2015 20:19:45 -0400 To: "Bill Ver Steeg (versteb)" , Jonathan Morton Message-ID: <8f89df95-d238-4b8a-b873-8fb43f584043@reed.com> Cc: =?ISO-8859-1?Q?R=E9mi_Cardona?= , "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cerowrt-devel] [Bloat] marketing #102 - giving netperf-wrapper a better name? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 00:20:19 -0000 ------WXENMZTC29VGSNNCH3YF6KRTFBO1FJ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Drag is an fluid dynamic term that suggests a meaning close to this=2E=2E= =2E flow rate dependent friction=2E But what you really want to suggest is= a flow rate dependent *delay* that people are familiar with quantifying=2E= Fq_codel limits the delay as flow rate increases and is fair=2E The max = buffer limits delay due to Little's lemma also=2E The actual delay limit i= n practice is what one measures in most cases=2E Codel is just softer than = the hard limit of a small buffer=2E So there are two qualitative measures = - delay limit in units of milliseconds and softness or stiffness in units o= f milliseconds per queue depth I'd guess=2E Softness gives the recovery rat= e after a burst=2E You should divide delay limit by elephant packet size i= n milliseconds=2E Based on channel rate=2E I'd think the scaled delay limi= t should On Mar 20, 2015, "Bill Ver Steeg (versteb)" = wrote: >I was kidding about "sucks-less", and forgot the smiley in my init= ial >note=2E > >We do need a metric with an end-user-friendly name, though= =2E Most people >understand "lag", and understand that lower numbers are be= tter=2E You >could probably explain "lag-while-loaded" to most users (parti= cularly >people who care, like gamers) in a manner that got the point acros= s=2E > >Bvs > > >-----Original Message----- >From: Jonathan Morton [mailto:= chromatix99@gmail=2Ecom] >Sent: Friday, March 20, 2015 4:26 PM >To: Bill V= er Steeg (versteb) >Cc: R=C3=A9mi Cardona; bloat; cerowrt-devel@lists=2Ebuf= ferbloat=2Enet >Subject: Re: [Bloat] marketing #102 - giving netperf-wrappe= r a better >name? > > >> On 20 Mar, 2015, at 22:08, Bill Ver Steeg (versteb= ) > wrote: >> >> We should call the metric "sucks-les= s"=2E As in "Box A sucks less than >Box B", or "Box C scored a 17 on the su= cks less test"=2E > >I suspect real marketing drones would get nervous at a= >negative-sounding name=2E > >My idea - which I=E2=80=99ve floated in the = past, more than once - is that the >metric should be =E2=80=9Cresponsivenes= s=E2=80=9D, measured in Hertz=2E The baseline >standard would be 10Hz, cor= responding to a dumb 100ms buffer=2E Get down >into the single-digit milli= second range, as fq_codel does, and the >Responsiveness goes up above 100Hz= , approaching 1000Hz=2E > >Crucially, that=E2=80=99s a positive sort of ter= m, as well as trending towards >bigger numbers with actual improvements in = performance, and is thus >more potentially marketable=2E > > - Jonathan Mor= ton > >_______________________________________________ >Cerowrt-devel maili= ng list >Cerowrt-devel@lists=2Ebufferbloat=2Enet >https://lists=2Ebufferblo= at=2Enet/listinfo/cerowrt-devel -- Sent with K-@ Mail - the evolution of e= mailing=2E ------WXENMZTC29VGSNNCH3YF6KRTFBO1FJ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Drag is an fluid dynamic term that suggests a mean= ing close to this=2E=2E=2E flow rate dependent friction=2E

But what you really want to suggest is a flow rate d= ependent *delay* that people are familiar with quantifying=2E

Fq_codel limits the delay as flow rate increases = and is fair=2E

The max buffer limits= delay due to Little's lemma also=2E

= The actual delay limit in practice is what one measures in most cases=2E C= odel is just softer than the hard limit of a small buffer=2E

So there are two qualitative measures - delay limi= t in units of milliseconds and softness or stiffness in units of millisecon= ds per queue depth I'd guess=2E Softness gives the recovery rate after a bu= rst=2E

You should divide delay limit= by elephant packet size in milliseconds=2E Based on channel rate=2E

I'd think the scaled delay limit should
On Mar 20, 20= 15, "Bill Ver Steeg (versteb)" <versteb@cisco=2Ecom> wrote:=
I was kidding about "sucks-less", and forgot the smiley =
in my initial note=2E

We do need a met= ric with an end-user-friendly name, though=2E Most people understand "= lag", and understand that lower numbers are better=2E You could probab= ly explain "lag-while-loaded" to most users (particularly people = who care, like gamers) in a manner that got the point across=2E

Bvs


-----Original Message-----
From: Jonathan Mort= on [mailto:chromatix99@gmail=2Ecom]
Sent: Friday, March = 20, 2015 4:26 PM
To: Bill Ver Steeg (versteb)
Cc: Rémi Cardona; bloat; cerowrt-devel@lists=2Ebufferbloat=2E= net
Subject: Re: [Bloat] marketing #102 - giving netperf-= wrapper a better name?


On 20 Mar, 2015= , at 22:08, Bill Ver Steeg (versteb) <versteb@cisco=2Ecom> wrote:

We should call the metric "sucks-les= s"=2E As in "Box A sucks less than Box B", or "Box C sc= ored a 17 on the sucks less test"=2E

I = suspect real marketing drones would get nervous at a negative-sounding name= =2E

My idea - which I’ve floated= in the past, more than once - is that the metric should be “responsi= veness”, measured in Hertz=2E The baseline standard would be 10Hz, c= orresponding to a dumb 100ms buffer=2E Get down into the single-digit mill= isecond range, as fq_codel does, and the Responsiveness goes up above 100Hz= , approaching 1000Hz=2E

Crucially, tha= t’s a positive sort of term, as well as trending towards bigger numbe= rs with actual improvements in performance, and is thus more potentially ma= rketable=2E

- Jonathan Morton



Cerowrt-devel mailing l= ist
Cerowrt-devel@lists=2Ebufferbloat=2Enet
https://lists=2Ebufferbloat=2Enet/listinfo/cerowrt-devel<= br clear=3D"none">

-- Sent with K-@ Mail - the evolution of emailing= =2E ------WXENMZTC29VGSNNCH3YF6KRTFBO1FJ--