From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp122.iad3a.emailsrvr.com (smtp122.iad3a.emailsrvr.com [173.203.187.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5C8583CB36 for ; Tue, 14 May 2019 14:38:52 -0400 (EDT) Received: from smtp16.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 12D2A5E06; Tue, 14 May 2019 14:38:52 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp16.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0C0C65E29; Tue, 14 May 2019 14:38:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1557859131; bh=DYUnh1eEAsbV9Np7vtyj5j68Drmg2V6l+chty2nD0PE=; h=Date:Subject:From:To:From; b=txmixBpb1b7GT9vRbbBC8sD9mo7BpKSJZ2pLdEiG/WoF1F6lo+MzUKXrOQu6L1a61 PDPwcSVlCESRb+mbYFj2znE16aO20kGgMNRxEAxJ6PApLjq7/3jg+hW3JVNWPbdGfX 2IlggtJb985Qgt8RpmboYwgvKn511it2A0DUBchg= Received: from app50.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D47455E06; Tue, 14 May 2019 14:38:51 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app50.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Tue, 14 May 2019 14:38:51 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app50.wa-webapps.iad3a (Postfix) with ESMTP id B9E8360046; Tue, 14 May 2019 14:38:51 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Tue, 14 May 2019 14:38:51 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Tue, 14 May 2019 14:38:51 -0400 (EDT) From: "David P. Reed" To: "=?utf-8?Q?Valdis_Kl=C4=93tnieks?=" Cc: "Rich Brown" , "cerowrt-devel" , "bloat" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20190514143851000000_63785" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <2936.1557856670@turing-police> References: <2936.1557856670@turing-police> Message-ID: <1557859131.759530583@apps.rackspace.com> X-Mailer: webmail/16.4.2-RC Subject: Re: [Bloat] =?utf-8?q?=5BCerowrt-devel=5D_fq=5Fcodel_is_SEVEN_years_o?= =?utf-8?b?bGQgdG9kYXkuLi4=?= 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: Tue, 14 May 2019 18:38:52 -0000 ------=_20190514143851000000_63785 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AWell, of all the devices in my house (maybe 100), only the router attach= ed to the cable modem (which is a 2x GigE Intel Linux board based on Fedora= 29 server with sch_cake configured) is running fq_codel. And setting that = up was a labor of love. But it works a charm for my asymmetric Gigabit cabl= e service.=0A =0AMy home's backbone is 10 GigE fiber, so I suppose fq_codel= would be helpful for devices that run on 1 GigE subnets like my 2 802.11ac= access points when talking to my NAS's.=0AHowever, the 802.11ac access poi= nt high speed functionality doesn't seem to be supportable by LEDE. So what= can I do? =0A =0AI suppose I could stick some little custom Intel Linux 2x= GigE devices between access points and the 10 GigE backbone, and put fq_co= del in there.=0A =0AMy point is, to get the primary benefit of bufferbloat = reduction, one has to stick little Linux boxes everywhere, because fq_codel= is not supported except via DIY hacking.=0A =0AAnd indeed, 10 GigE->1 GigE= buffering does affect storage access latency in bad ways.=0A =0AWe see the= same problem in datacenter networks that have excessive buffering - a famo= us switch company backed by Andy Bechtolsheim is really problematic because= they claim building up huge buffers is a "feature" not a bug.=0A-----Origi= nal Message-----=0AFrom: "Valdis Kl=C4=93tnieks" = =0ASent: Tuesday, May 14, 2019 1:57pm=0ATo: "Rich Brown" =0ACc: "cerowrt-devel" , "bloat= " =0ASubject: Re: [Cerowrt-devel] fq_codel is = SEVEN years old today...=0A=0A=0A=0A_______________________________________= ________=0ACerowrt-devel mailing list=0ACerowrt-devel@lists.bufferbloat.net= =0Ahttps://lists.bufferbloat.net/listinfo/cerowrt-devel=0AOn Tue, 14 May 20= 19 08:16:06 -0400, Rich Brown said:=0A=0A> Let's all pat ourselves on the b= ack for this good work!=0A=0ADo we have an estimate of what percent of conn= ected devices=0Aare actually using fq_codel or other modern anti-bloat meth= ods?=0AI'm reasonably sure my TV, my PS3, and my PS4 are still=0Abehind the= curve. ------=_20190514143851000000_63785 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Well, of all the devic= es in my house (maybe 100), only the router attached to the cable modem (wh= ich is a 2x GigE Intel Linux board based on Fedora 29 server with sch_cake = configured) is running fq_codel. And setting that up was a labor of love. B= ut it works a charm for my asymmetric Gigabit cable service.

=0A

 

=0A

My home's backbone is 10 Gig= E fiber, so I suppose fq_codel would be helpful for devices that run on 1 G= igE subnets like my 2 802.11ac access points when talking to my NAS's.

= =0A

However, the 802.11ac access point high speed funct= ionality doesn't seem to be supportable by LEDE. So what can I do? =0A

 

=0A

I suppose I coul= d stick some little custom Intel Linux 2x GigE devices between access point= s and the 10 GigE backbone, and put fq_codel in there.

=0A

 

=0A

My point is, to get the primary be= nefit of bufferbloat reduction, one has to stick little Linux boxes everywh= ere, because fq_codel is not supported except via DIY hacking.

=0A

 

=0A

And indeed, 10 GigE->1 = GigE buffering does affect storage access latency in bad ways.

=0A

 

=0A

We see the same problem in= datacenter networks that have excessive buffering - a famous switch compan= y backed by Andy Bechtolsheim is really problematic because they claim buil= ding up huge buffers is a "feature" not a bug.

=0A

-= ----Original Message-----
From: "Valdis Kl=C4=93tnieks" <valdis.kle= tnieks@vt.edu>
Sent: Tuesday, May 14, 2019 1:57pm
To: "Rich Br= own" <richb.hanover@gmail.com>
Cc: "cerowrt-devel" <cerowrt-d= evel@lists.bufferbloat.net>, "bloat" <bloat@lists.bufferbloat.net>=
Subject: Re: [Cerowrt-devel] fq_codel is SEVEN years old today...

=0A
=0A

___= ____________________________________________
Cerowrt-devel mailing lis= t
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.n= et/listinfo/cerowrt-devel
On Tue, 14 May 2019 08:16:06 -0400, Rich Bro= wn said:

> Let's all pat ourselves on the back for this good = work!

Do we have an estimate of what percent of connected device= s
are actually using fq_codel or other modern anti-bloat methods?
I'm reasonably sure my TV, my PS3, and my PS4 are still
behind the cu= rve.

=0A
 ------=_20190514143851000000_63785--