From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp181.iad.emailsrvr.com (smtp181.iad.emailsrvr.com [207.97.245.181]) (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 5F359202102 for ; Fri, 1 Mar 2013 08:27:09 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp48.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 39ED116924E; Fri, 1 Mar 2013 11:27:08 -0500 (EST) X-Virus-Scanned: OK Received: from legacy5.wa-web.iad1a (legacy5.wa-web.iad1a.rsapps.net [192.168.2.221]) by smtp48.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 153AE1691F8; Fri, 1 Mar 2013 11:27:08 -0500 (EST) Received: from reed.com (localhost [127.0.0.1]) by legacy5.wa-web.iad1a (Postfix) with ESMTP id 017092E9802E; Fri, 1 Mar 2013 11:27:08 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Fri, 1 Mar 2013 11:27:08 -0500 (EST) Date: Fri, 1 Mar 2013 11:27:08 -0500 (EST) From: dpreed@reed.com To: "Jim Gettys" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20130301112708000000_96277" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <1362077845.101114942@apps.rackspace.com> <1362152412.065117928@apps.rackspace.com> Message-ID: <1362155228.00438500@apps.rackspace.com> X-Mailer: webmail7.0 Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Google working on experimental 3.8 Linux kernel for Android 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: Fri, 01 Mar 2013 16:27:09 -0000 ------=_20130301112708000000_96277 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI don't doubt that they test. My point was different - there are too ma= ny knobs and too big a parameter space to test efectively. And that's the = point.=0A =0AI realize that it's extremely fun to invent parameters in "sta= ndards organizations" like 3GPP. Everybody has their own favorite knob, an= d a great rationale for some unusual, but critically "important" customer r= equirement that might come up some day. Hell, Linux has a gazillion (yes, = that's a technical term in mathematics!) parameters, almost none of which a= re touched. This reflects the fact that nothing ever gets removed once add= ed. LTE is now going into release 12, and it's completely ramified into "s= olutions" to problems that will never be fixed in the field with those solu= tions. It's great for European Publically Funded Academic-Industry researc= h - lots for those "Professors" to claim they invented.=0A =0AI've worked w= ith telco contractors in the field. They don't read manuals, and they don= 't read specs. They have a job to do, and so much money to spend, and time= 's a wasting. They don't even work for Verizon or ATT. They follow "specs= " handed down, and charge more if you tell them that the specs have changed= .=0A =0AThis is not how brand-new systems get tuned.=0A =0AIt's a Clown Cir= cus out there, and more parameters don't help.=0A =0AThis is why "more buff= ering is better" continues to be the law of the land - the spec is defined = to be "no lost packets under load". I'm sure that the primary measure und= er load for RRUL will be "no lost packets" by the time it gets to field eng= ineers in the form of "specs" - because that's what they've *always* been t= old, and they will disregard any changes as "typos".=0A =0AA system with mo= re than two control parameters that interact in complex ways is ungovernabl= e - and no control parameters in LTE are "orthogonal", much less "linear" i= n their interaction.=0A =0A =0A =0A-----Original Message-----=0AFrom: "Jim = Gettys" =0ASent: Friday, March 1, 2013 11:09am=0ATo: "D= avid P Reed" =0ACc: "Ketan Kulkarni" ,= "cerowrt-devel@lists.bufferbloat.net" =0ASubject: Re: [Cerowrt-devel] Google working on experimental 3.8 Linux k= ernel for Android=0A=0A=0A=0A=0A=0A=0A=0A=0AOn Fri, Mar 1, 2013 at 10:40 AM= , <[mailto:dpreed@reed.com] dpreed@reed.com> wrote:=0A=0AOne wonders why a= ll this complexity is necessary, and how likely it is to be "well tuned" by= operators and their contract installers.=0A =0AI'm willing to bet $1000 th= at all the testing that is done is "Can you hear me now" and a "speed test"= . Not even something as simple and effective as RRUL.=0AActually, at least= some the the carriers do much more extensive testing; but not with the tes= t tools we would like to see used (yet).=0AAn example is AT&T, where in res= earch, KK Ramakrishnan has a van with 20 or so laptops so he can go driving= around and load up a cell in the middle of the night and get data. And h= e's research; the operations guys do lots of testing I gather, but more at = the radio level.=0ANext up, is to educate KK to run RRUL.=0AAnd in my own c= ompany, I've seen data, but it is too high level: e.g. performance of "web"= video: e.g. siverlight, flash, youtube, etc.=0AA common disease that has c= omplicated all this is the propensity for companies to use Windows XP inter= nally for everything: since window scaling is turned off, you can't saturat= e a LTE link the way you might like to do with a single TCP connection.=0A-= Jim=0A=0A=0A=0A =0A-----Original Message-----=0AFrom: "Ketan Kulkarni" <[m= ailto:ketkulka@gmail.com] ketkulka@gmail.com>=0ASent: Friday, March 1, 2013= 3:00am=0ATo: "Jim Gettys" <[mailto:jg@freedesktop.org] jg@freedesktop.org>= =0A Cc: "[mailto:cerowrt-devel@lists.bufferbloat.net] cerowrt-devel@lists.b= ufferbloat.net" <[mailto:cerowrt-devel@lists.bufferbloat.net] cerowrt-devel= @lists.bufferbloat.net>=0A Subject: Re: [Cerowrt-devel] Google working on e= xperimental 3.8 Linux kernel for Android=0A=0A=0A=0A=0A=0AOn Fri, Mar 1, 20= 13 at 1:33 AM, Jim Gettys <[mailto:jg@freedesktop.org] jg@freedesktop.org> = wrote:=0A=0AI've got a bit more insight into LTE than I did in the past, co= urtesy of the last couple days.=0ATo begin with, LTE runs with several clas= ses of service (the call them bearers). Your VOIP traffic goes into one of= them.=0AAnd I think there is another as well that is for guaranteed bit ra= te traffic. One transmit opportunity may have a bunch of chunks of data, a= nd that data may be destined for more than one device (IIRC). It's substan= tially different than WiFi.=0AJust thought to put more light on bearer stuf= f:=0A=0AThere are two ways bearers are setup: =0A1. UE initiated - where Us= er Equipment sets-up the "parameters" for bearer =0A 2. Network initiated -= where node like PCRF and PGW sets-up the "parameters". =0A Parameters incl= ude the Guaranteed bit-rates, maximum bit-rates. Something called QCI is as= sociated with bearers. The QCI parameters are authorized at PCRF (policy co= ntrol rule function) and there is certain mapping maintained at either PCRF= or PGW between QCI values and DSCP and MBRs.=0A These parameters enforcing= is done at PGW (in such case it is termed as PCEF - policy and rule enforc= ement function). So PGWs depending on bearers can certainly modify dscp bit= s. Though these can be modified by other nodes in the network. =0A=0AThere = are two types of bearers: 1. Dedicated bearers - to carry traffic which nee= d "special" treatment 2. Default or general pupose bearers - to carry all g= eneral purpose data.=0ASo generally the voip, streaming videos are passed o= ver dedicated bearers and apply (generally) higher GBRs, MBRs and correct d= scp markings.=0A And other non-latency sensitive traffic generally follows = the default bearer.=0A=0ATheoretical limit on maximum bearers is 11 though = practically most of the deployments use upto 3 bearers max.=0A=0ANote that = these parameters may very well very based on the subscriber profiles. Premi= um/Corporate subscribers can well have more GBRs and MBRs.=0A ISPs are gene= rally very much sensitive to the correct markings at gateways for obvious r= easons.=0A=0A=0A=0ABut most of what we think of as Internet stuff (web surf= ing, dns, etc) all gets dumped into a single best effort ("BE"), class.=0AT= he BE class is definitely badly bloated; I can't say how much because I don= 't really know yet; the test my colleague ran wasn't run long enough to be = confident it filled the buffers). But I will say worse than most cable mod= ems I've seen. I expect this will be true to different degrees on differen= t hardware. The other traffic classes haven't been tested yet for bufferbl= oat, though I suspect they will have it too. I was told that those classes= have much shorter queues, and when the grow, they dump the whole queues (b= ecause delivering late real time traffic is useless). But trust *and* veri= fy.... Verification hasn't been done for anything but BE traffic, and that= hasn't been quantified.=0ABut each device gets a "fair" shot at bandwidth = in the cell (or sector of a cell; they run 3 radios in each cell), where fa= ir is basically time based; if you are at the edge of a cell, you'll get a = lot less bandwidth than someone near a tower; and this fairness is guarante= ed by a scheduler than runs in the base station (called a b-nodeb, IIIRC). = So the base station guarantees some sort of "fairness" between devices (a = place where Linux's wifi stack today fails utterly, since there is a single= queue per device, rather than one per station).=0AWhether there are bloat = problems at the link level in LTE due to error correction I don't know yet;= but it wouldn't surprise me; I know there was in 3g. The people I talked = to this morning aren't familiar with the HARQ layer in the system.=0AThe ba= se stations are complicated beasts; they have both a linux system in them a= s well as a real time operating system based device inside We don't know w= here the bottle neck(s) are yet. I spent lunch upping their paranoia and g= etting them through some conceptual hurdles (e.g. multiple bottlenecks that= may move, and the like). They will try to get me some of the data so I ca= n help them figure it out. I don't know if the data flow goes through the = linux system in the bnodeb or not, for example.=0AMost carriers are now try= ing to ensure that their backhauls from the base station are never congeste= d, though that is another known source of problems. And then there is the = lack of AQM at peering point routers.... You'd think they might run WRED t= here, but many/most do not.=0A- Jim=0A=0A=0A=0A=0A=0AOn Thu, Feb 28, 2013 a= t 2:08 PM, Dave Taht <[mailto:dave.taht@gmail.com] dave.taht@gmail.com> wro= te:=0A=0A=0A=0A=0AOn Thu, Feb 28, 2013 at 1:57 PM, <[mailto:dpreed@reed.co= m] dpreed@reed.com> wrote:=0A=0ADoesn't fq_codel need an estimate of link c= apacity?=0ANo, it just measures delay. Since so far as I know the outgoing = portion of LTE is not soft-rate limited, but sensitive to the actual availa= ble link bandwidth, fq_codel should work pretty good (if the underlying int= erfaces weren't horribly overbuffired) in that direction.=0AI'm looking for= ward to some measurements of actual buffering at the device driver/device l= evels.=0AI don't know how inbound to the handset is managed via LTE.=0AStil= l quite a few assumptions left to smash in the above.=0A...=0Ain the home r= outer case....=0A...=0AWhen there are artificial rate limits in play (in, f= or example, a cable modem/CMTS, hooked up via gigE yet rate limiting to 24u= p/4mbit down), then a rate limiter (tbf,htb,hfsc) needs to be applied local= ly to move that rate limiter/queue management into the local device, se we = can manage it better.=0AI'd like to be rid of the need to use htb and come = up with a rate limiter that could be adjusted dynamically from a daemon in = userspace, probing for short all bandwidth fluctuations while monitoring th= e load. It needent send that much data very often, to come up with a stable= result....=0AYou've described one soft-rate sensing scheme (piggybacking o= n TCP), and I've thought up a few others, that could feed back from a daemo= n some samples into a a soft(er) rate limiter that would keep control of th= e queues in the home router. I am thinking it's going to take way too long = to fix the CPE and far easier to fix the home router via this method, and c= ertainly it's too painful and inaccurate to merely measure the bandwidth on= ce, then set a hard rate, when=0ASo far as I know the gargoyle project was = experimenting with this approach.=0AA problem is in places that connect mor= e than one device to the cable modem... then you end up with those needing = to communicate their perception of the actual bandwidth beyond the link.=0A= =0A=0AWhere will it get that from the 4G or 3G uplink?=0A=0A=0A =0A-----Ori= ginal Message-----=0AFrom: "Maciej Soltysiak" <[mailto:maciej@soltysiak.com= ] maciej@soltysiak.com>=0ASent: Thursday, February 28, 2013 1:03pm=0A To: [= mailto:cerowrt-devel@lists.bufferbloat.net] cerowrt-devel@lists.bufferbloat= .net=0ASubject: [Cerowrt-devel] Google working on experimental 3.8 Linux ke= rnel for Android=0A=0A=0A=0AHiya,=0ALooks like Google's experimenting with = 3.8 for Android: [https://android.googlesource.com/kernel/common/+/experime= ntal/android-3.8] https://android.googlesource.com/kernel/common/+/experime= ntal/android-3.8=0ASounds great if this means they will utilize fq_codel, T= FO, BQL, etc.=0AAnyway my nexus 7 says it has 3.1.10 and this 3.8 will prob= ably go to Android 5.0 so I hope Nexus 7 will get it too some day or at lea= st 3.3+=0APhoronix coverage: [http://www.phoronix.com/scan.php?page=3Dnews_= item&px=3DMTMxMzc] http://www.phoronix.com/scan.php?page=3Dnews_item&px=3DM= TMxMzc=0ATheir 3.8 changelog: [https://android.googlesource.com/kernel/comm= on/+log/experimental/android-3.8] https://android.googlesource.com/kernel/c= ommon/+log/experimental/android-3.8=0ARegards,=0AMaciej____________________= ___________________________=0A Cerowrt-devel mailing list=0A[mailto:Cerowrt= -devel@lists.bufferbloat.net] Cerowrt-devel@lists.bufferbloat.net=0A[https:= //lists.bufferbloat.net/listinfo/cerowrt-devel] https://lists.bufferbloat.n= et/listinfo/cerowrt-devel=0A=0A=0A=0A-- =0ADave T=C3=A4ht=0A=0AFixing buffe= rbloat with cerowrt: [http://www.teklibre.com/cerowrt/subscribe.html] http:= //www.teklibre.com/cerowrt/subscribe.html =0A _____________________________= __________________=0A Cerowrt-devel mailing list=0A[mailto:Cerowrt-devel@li= sts.bufferbloat.net] Cerowrt-devel@lists.bufferbloat.net=0A[https://lists.b= ufferbloat.net/listinfo/cerowrt-devel] https://lists.bufferbloat.net/listin= fo/cerowrt-devel=0A=0A=0A_______________________________________________=0A= Cerowrt-devel mailing list=0A[mailto:Cerowrt-devel@lists.bufferbloat.net] = Cerowrt-devel@lists.bufferbloat.net=0A[https://lists.bufferbloat.net/listin= fo/cerowrt-devel] https://lists.bufferbloat.net/listinfo/cerowrt-devel=0A= =0A ------=_20130301112708000000_96277 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= I don't doubt that they test.  My point was different - there are too = many knobs and too big a parameter space to test efectively.  And that= 's the point.

=0A

 

=0A

I realize that it's extremely fun to invent parame= ters in "standards organizations" like 3GPP.  Everybody has their own = favorite knob, and a great rationale for some unusual, but critically "impo= rtant" customer requirement that might come up some day.  Hell, Linux = has a gazillion (yes, that's a technical term in mathematics!) parameters, = almost none of which are touched.  This reflects the fact that nothing= ever gets removed once added.  LTE is now going into release 12, and = it's completely ramified into "solutions" to problems that will never be fi= xed in the field with those solutions.  It's great for European Public= ally Funded Academic-Industry research - lots for those "Professors" to cla= im they invented.

=0A

 

=0A

I've worked with telco contractors in the field= .   They don't read manuals, and they don't read specs.  The= y have a job to do, and so much money to spend, and time's a wasting. = They don't even work for Verizon or ATT.  They follow "specs" handed = down, and charge more if you tell them that the specs have changed.

=0A<= p style=3D"margin:0;padding:0;"> 

=0A

This is not how brand-new systems get tuned.

=0A

 

=0A

It's a Clown Circ= us out there, and more parameters don't help.

=0A

 

=0A

This is why "more b= uffering is better" continues to be the law of the land - the spec is defin= ed to be "no lost packets under load".   I'm sure that the primar= y measure under load for RRUL will be "no lost packets" by the time it gets= to field engineers in the form of "specs" - because that's what they've *a= lways* been told, and they will disregard any changes as "typos".

=0A

 

=0A

A system with more than two control parameters that interact in complex wa= ys is ungovernable - and no control parameters in LTE are "orthogonal", muc= h less "linear" in their interaction.

=0A

 

=0A

 

=0A

 

=0A

-----Origi= nal Message-----
From: "Jim Gettys" <jg@freedesktop.org>
Se= nt: Friday, March 1, 2013 11:09am
To: "David P Reed" <dpreed@reed.c= om>
Cc: "Ketan Kulkarni" <ketkulka@gmail.com>, "cerowrt-devel= @lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>
Su= bject: Re: [Cerowrt-devel] Google working on experimental 3.8 Linux kernel = for Android

=0A
=0A

=0A


=0A
On Fri, Mar 1, 2013 at 10:40 AM, <dpreed@reed.com> wrote:
=0A
=0A

One wonders why all this complexity is necessary, and how likely it= is to be "well tuned" by operators and their contract installers.

=0A 

=0A

I'm willing to bet $1000 tha= t all the testing that is done is "Can you hear me now" and a "speed test".=   Not even something as simple and effective as RRUL.

=0A=0A
Actually, at least some the the carriers do much more ext= ensive testing; but not with the test tools we would like to see used (yet)= .
=0A
An example is AT&T, where in research, KK Ramakrishnan h= as a van with 20 or so laptops so he can go driving around and load up a ce= ll in the middle of the night and get data.   And he's research; the o= perations guys do lots of testing I gather, but more at the radio level.=0A
Next up, is to educate KK to run RRUL.
=0A
And in my ow= n company, I've seen data, but it is too high level: e.g. performance of "w= eb" video: e.g. siverlight, flash, youtube, etc.
=0A
A common dise= ase that has complicated all this is the propensity for companies to use Wi= ndows XP internally for everything: since window scaling is turned off, you= can't saturate a LTE link the way you might like to do with a single TCP c= onnection.
=0A
- Jim
=0A
=0A
=0A
=0A=0A

&nb= sp;

=0A

-----Origi= nal Message-----
From: "Ketan Kulkarni" <ketkulka@gmail.com>
Sent: Friday,= March 1, 2013 3:00am
To: "Jim Gettys" <jg@freedesktop.org>
Cc: "cerowrt-d= evel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net&g= t;
Subject: Re: [Cerowrt-devel] Google working on experimental 3.8 Li= nux kernel for Android

=0A


=0A
On Fri, Mar 1, 2013 at 1:33 AM, Jim Gettys &= lt;jg@freedesktop.o= rg> wrote:
=0A
=0AI've got a bit more insight into LTE than I did in the past,= courtesy of the last couple days.=0A
To begin with, LTE runs with seve= ral classes of service (the call them bearers).  Your VOIP traffic goe= s into one of them.
=0A
And I think there is another as well that = is for guaranteed bit rate traffic.  One transmit opportunity may have= a bunch of chunks of data, and that data may be destined for more than one= device (IIRC).  It's substantially different than WiFi.
=0A=0A
=0A
Just thought to put more light on bearer stuff:
There are two ways bearers are setup:
1. UE initiated - wher= e User Equipment sets-up the "parameters" for bearer
2. Network init= iated - where node like PCRF and PGW sets-up the "parameters".
Param= eters include the Guaranteed bit-rates, maximum bit-rates. Something called= QCI is associated with bearers. The QCI parameters are authorized at PCRF = (policy control rule function) and there is certain mapping maintained at e= ither PCRF or PGW between QCI values and DSCP and MBRs.
These paramet= ers enforcing is done at PGW (in such case it is termed as PCEF - policy an= d rule enforcement function). So PGWs depending on bearers can certainly mo= dify dscp bits. Though these can be modified by other nodes in the network.=

There are two types of bearers: 1. Dedicated bearers - to carr= y traffic which need "special" treatment 2. Default or general pupose beare= rs - to carry all general purpose data.
So generally the voip, streami= ng videos are passed over dedicated bearers and apply (generally) higher GB= Rs, MBRs and correct dscp markings.
And other non-latency sensitive t= raffic generally follows the default bearer.

Theoretical limit o= n maximum bearers is 11 though practically most of the deployments use upto= 3 bearers max.

Note that these parameters may very well very ba= sed on the subscriber profiles. Premium/Corporate subscribers can well have= more GBRs and MBRs.
ISPs are generally very much sensitive to the co= rrect markings at gateways for obvious reasons.

=0A=0A
=0A
But most of what = we think of as Internet stuff (web surfing, dns, etc) all gets dumped into = a single best effort ("BE"), class.
=0A
The BE class is defin= itely badly bloated; I can't say how much because I don't really know = yet; the test my colleague ran wasn't run long enough to be confident it fi= lled the buffers).  But I will say worse than most cable modems I've s= een.  I expect this will be true to different degrees on different har= dware.  The other traffic classes haven't been tested yet for bufferbl= oat, though I suspect they will have it too.  I was told that those cl= asses have much shorter queues, and when the grow, they dump the whole queu= es (because delivering late real time traffic is useless).  But trust = *and* verify....  Verification hasn't been done for anything but BE tr= affic, and that hasn't been quantified.
=0A
But each device gets a= "fair" shot at bandwidth in the cell (or sector of a cell; they run 3 radi= os in each cell), where fair is basically time based; if you are at the edg= e of a cell, you'll get a lot less bandwidth than someone near a tower; and= this fairness is guaranteed by a scheduler than runs in the base station (= called a b-nodeb, IIIRC).  So the base station guarantees some sort of= "fairness" between devices (a place where Linux's wifi stack today fails u= tterly, since there is a single queue per device, rather than one per stati= on).
=0A
Whether there are bloat problems at the link level in LTE= due to error correction I don't know yet; but it wouldn't surprise me; I k= now there was in 3g.  The people I talked to this morning aren't famil= iar with the HARQ layer in the system.
=0A
The base stations are c= omplicated beasts; they have both a linux system in them as well as a real = time operating system based device inside  We don't know where the bot= tle neck(s) are yet.  I spent lunch upping their paranoia and getting = them through some conceptual hurdles (e.g. multiple bottlenecks that may mo= ve, and the like).  They will try to get me some of the data so I can = help them figure it out.  I don't know if the data flow goes through t= he linux system in the bnodeb or not, for example.
=0A
Most carrie= rs are now trying to ensure that their backhauls from the base station are = never congested, though that is another known source of problems.  And= then there is the lack of AQM at peering point routers....  You'd thi= nk they might run WRED there, but many/most do not.
=0A=0A
- Jim
=0A
=0A
= =0A
=0A


=0A
On Thu, Feb 28, 2013 at 2:08 PM, Dave Taht <dave.taht@gmail.com= > wrote:
=0A


=0A
=0A
On Thu, Feb 28, 2013 at 1:57 PM, <dp= reed@reed.com> wrote:
=0A
=0A

Doesn't fq_codel need an estimate of lin= k capacity?

=0A
=0A
=0A
No, it just measures= delay. Since so far as I know the outgoing portion of LTE is not soft-rate= limited, but sensitive to the actual available link bandwidth, fq_codel sh= ould work pretty good (if the underlying interfaces weren't horribly overbu= ffired) in that direction.
=0A
I'm looking forward to some measure= ments of actual buffering at the device driver/device levels.
=0A
= I don't know how inbound to the handset is managed via LTE.
=0A
St= ill quite a few assumptions left to smash in the above.
=0A
...=0A
in the home router case....
=0A
...
=0A
When t= here are artificial rate limits in play (in, for example, a cable modem/CMT= S, hooked up via gigE yet rate limiting to 24up/4mbit down), then a rate li= miter (tbf,htb,hfsc) needs to be applied locally to move that rate limiter/= queue management into the local device, se we can manage it better.
= =0A
I'd like to be rid of the need to use htb and come up with a rate l= imiter that could be adjusted dynamically from a daemon in userspace, probi= ng for short all bandwidth fluctuations while monitoring the load. It neede= nt send that much data very often, to come up with a stable result....=0A
You've described one soft-rate sensing scheme (piggybacking on TCP= ), and I've thought up a few others, that could feed back from a daemon som= e samples into a a soft(er) rate limiter that would keep control of the que= ues in the home router. I am thinking it's going to take way too long to fi= x the CPE and far easier to fix the home router via this method, and certai= nly it's too painful and inaccurate to merely measure the bandwidth once, t= hen set a hard rate, when
=0A
So far as I know the gargoyle projec= t was experimenting with this approach.
=0A
A problem is in places= that connect more than one device to the cable modem... then you end up wi= th those needing to communicate their perception of the actual bandwidth be= yond the link.
=0A
=0A
=0A=0A

Where will it get that from the 4G or 3G upli= nk?

=0A
=0A
=0A

 

=0A

-= ----Original Message-----
From: "Maciej Soltysiak" <maciej@soltysiak.com>
Sent: Thursday, February 28, 2013 1:03pm
To: cerowrt-devel@lists.buff= erbloat.net
Subject: [Cerowrt-devel] Google working on experimenta= l 3.8 Linux kernel for Android

=0A
=0A
Hiya,
= =0A
Looks like Google's experimenting with 3.8 for Android: https://android.googlesource.com/kernel/common/+/experime= ntal/android-3.8
=0A
Sounds great if this means they will util= ize fq_codel, TFO, BQL, etc.
=0A
Anyway my nexus 7 says it has 3.1= .10 and this 3.8 will probably go to Android 5.0 so I hope Nexus 7 will get= it too some day or at least 3.3+
=0A=0A=0A
Regards,
=0A
Maciej
=0A
=0A=0A
=0A
=0A
=0A____________________________________= ___________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferb= loat.net
https://lists.bufferbloat.net/listinfo/cerowrt-de= vel

=0A
=0A

--
Dave T=C3=A4ht

Fixing bufferbloat wi= th cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
_______________________________________________
Cerowrt-de= vel mailing list
Cerowrt-devel@lists.bufferbloat.net
ht= tps://lists.bufferbloat.net/listinfo/cerowrt-devel

=0A
=0A
=0A
=0A
=0A
__________________________= _____________________
Cerowrt-devel mailing list
Cerowrt-devel@lis= ts.bufferbloat.net
https://lists.bufferbloat.net/listinfo/= cerowrt-devel

=0A
=0A
=0A
=0A=0A=0A
=0A
=0A=0A ------=_20130301112708000000_96277--