From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp86.iad3a.emailsrvr.com (smtp86.iad3a.emailsrvr.com [173.203.187.86]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 7C4653B29D for ; Wed, 6 May 2020 11:39:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1588779543; bh=BRq2HR+e5w/gz/qtuugExrgaJiMMsYlmIwEuNh2Ndk8=; h=Date:Subject:From:To:From; b=NpSQM+uH7MMQvx1UL17G/XePDtfXOgTv563FSOcg8Fu1YmvYDUBjpV61qSMQkBaq9 0+6dPKHbmuTxyqGtVwSKQvmrwfVOzcy4oaHfQA72zPIIHIQ2O3lMe+QMbIqlaLL+I+ xmrw9VLMHaUSPSWNoU5qo4WJAWIWRwmic9aw1cM0= Received: from app35.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp11.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 25B4252E4; Wed, 6 May 2020 11:39:03 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app35.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Wed, 06 May 2020 11:39:03 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app35.wa-webapps.iad3a (Postfix) with ESMTP id 10911A104E; Wed, 6 May 2020 11:39:03 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Wed, 6 May 2020 11:39:03 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Wed, 6 May 2020 11:39:03 -0400 (EDT) From: "David P. Reed" To: "Sebastian Moeller" Cc: "Sergey Fedorov" , "=?utf-8?Q?Dave_T=C3=A4ht?=" , "Make-Wifi-fast" , "Jannie Hanekom" , "Cake List" , "bloat" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20200506113903000000_50998" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <1588518416.66682155@apps.rackspace.com> Message-ID: <1588779543.065923089@apps.rackspace.com> X-Mailer: webmail/17.3.10-RC X-Classification-ID: e635d89c-0d60-4873-9ecd-0327076ce7f9-1-1 Subject: [Bloat] Slightly OT Re: [Cake] [Make-wifi-fast] dslreports is no longer free X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 15:39:03 -0000 ------=_20200506113903000000_50998 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AWhile the jury is still out for me on the "best" speed test to recommend= to my friends, family, and even enemies, I think the progression has been = good.=0A =0AOriginally, I used to recommend the web-embedded Java test call= ed Netalyzer from ICSI. That did extensive tests, and included tests that a= re important to me like detecting DNS spoofing, various middlebox mucking w= ith packets, ... as well as measuring lag under load in a simple way. But t= hen I had to teach each person I recommended it to what everything meant. T= hat was a BIG burden on me.=0A =0AThen I switched to dslreports.com, becaus= e of several factors - it highlighted lag under load as a bufferbloat grade= that made sense.=0A =0ANow, I have to say that fast.com is likely to becom= e my new recommendation. However, I have two issues with it. The biggest on= e is that lag-under-load is obscured in the interface, as is the asymmetry = of upload vs. download.=0A =0AThe problem for me is that I usually get aske= d to recommend a test under circumstances where someone isn't looking for "= bragging rights" but is experiencing a problem of disrupted service quality= . The NUMBER ONE problem they usually have is the lag-under-load problem in= some form. But all they know is what "download speed" they bought.=0A =0AM= any, many people are using videoconferencing now, not just web and TV watch= ing. And that is hypersensitive to lag-under-load (also on WiFi due to airt= ime scheduling).=0AAnd no one seems to be aware that their quality of exper= ience is not about speed, but about instability of lag-under-load. So it's = a new idea.=0A =0AYeah, I do once in a while want to know if my service is = delivering the top speed advertised - just as I once in a while measure the= time of my car in the quarter mile on dragstrip :-)=0A =0ABut mostly I wan= t to know what's making my *applications* so slow. And it's almost never th= e case that they need a nitro-burning funny car level of speed. Instead, th= ey need either: elimination of lag under load, or eliminating all the crap = running in tabs on the browser (like animated JavaScript attention-seeking = ads filling memory with garbage and causing the JS garbage collector to run= constantly).=0A =0ASo I would change fast.com, if I could, to emphasize th= e *problems* (as netalyzer did) and not the speed. ------=_20200506113903000000_50998 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

While the jury is stil= l out for me on the "best" speed test to recommend to my friends, family, a= nd even enemies, I think the progression has been good.

=0A

 

=0A

Originally, I used to recommend t= he web-embedded Java test called Netalyzer from ICSI. That did extensive te= sts, and included tests that are important to me like detecting DNS spoofin= g, various middlebox mucking with packets, ... as well as measuring lag und= er load in a simple way. But then I had to teach each person I recommended = it to what everything meant. That was a BIG burden on me.

=0A

 

=0A

Then I switched to dslreports.c= om, because of several factors - it highlighted lag under load as a bufferb= loat grade that made sense.

=0A

 

=0A

Now, I have to say that fast.com is likely to become my new r= ecommendation. However, I have two issues with it. The biggest one is that = lag-under-load is obscured in the interface, as is the asymmetry of upload = vs. download.

=0A

 

=0A

= The problem for me is that I usually get asked to recommend a test under ci= rcumstances where someone isn't looking for "bragging rights" but is experi= encing a problem of disrupted service quality. The NUMBER ONE problem they = usually have is the lag-under-load problem in some form. But all they know = is what "download speed" they bought.

=0A

 

= =0A

Many, many people are using videoconferencing now, = not just web and TV watching. And that is hypersensitive to lag-under-load = (also on WiFi due to airtime scheduling).

=0A

And no= one seems to be aware that their quality of experience is not about speed,= but about instability of lag-under-load. So it's a new idea.

=0A

 

=0A

Yeah, I do once in a while = want to know if my service is delivering the top speed advertised - just as= I once in a while measure the time of my car in the quarter mile on dragst= rip :-)

=0A

 

=0A

But mo= stly I want to know what's making my *applications* so slow. And it's almos= t never the case that they need a nitro-burning funny car level of speed. I= nstead, they need either: elimination of lag under load, or eliminating all= the crap running in tabs on the browser (like animated JavaScript attentio= n-seeking ads filling memory with garbage and causing the JS garbage collec= tor to run constantly).

=0A

 

=0A

So I would change fast.com, if I could, to emphasize the *problem= s* (as netalyzer did) and not the speed.

 ------=_20200506113903000000_50998--