From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 71F8521F0B3 for ; Thu, 28 Feb 2013 11:08:51 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id k10so2505677iea.19 for ; Thu, 28 Feb 2013 11:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2ZO2bebEAMn7vS3FjZIL+qeWedsudONgfHCE3FyTPD8=; b=balZMD0kslwpzkNtA6Za6ol0VxDW8azAypGopFzEnInuNuNwqq7VUQFOE3MCp2CLbj nWVHcPhDoSd6zFn4yZN9NFcbs1a3PMqwdVlDDGahIzHPwXozvuIIUxutUYK/U+8EvzdB KcbsvjO9gbOZd0xmUhSMHnCZIVuLbUNhPY4pTdkvWgGVJMmkVRueVFCM4+Eu/txyB2yW diJD/oCHnHHMurMHtOkBpHjyzgttlH1llzEKLEFn6Mow95uo1Wt0ciHlMRKaevz6GHv8 8OLmonFGUyoN49M/UnWRw88RyYhjzsHdSIayHOqQP5eFSIZ/1wDwPNS6eyyvDn7RP8XF bEHw== MIME-Version: 1.0 X-Received: by 10.42.54.5 with SMTP id p5mr4047068icg.49.1362078530677; Thu, 28 Feb 2013 11:08:50 -0800 (PST) Received: by 10.64.223.170 with HTTP; Thu, 28 Feb 2013 11:08:50 -0800 (PST) In-Reply-To: <1362077845.101114942@apps.rackspace.com> References: <1362077845.101114942@apps.rackspace.com> Date: Thu, 28 Feb 2013 14:08:50 -0500 Message-ID: From: Dave Taht To: dpreed@reed.com Content-Type: multipart/alternative; boundary=90e6ba3fd72dfa318e04d6cd9ee7 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: Thu, 28 Feb 2013 19:08:51 -0000 --90e6ba3fd72dfa318e04d6cd9ee7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Feb 28, 2013 at 1:57 PM, wrote: > Doesn't fq_codel need an estimate of link capacity? > 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 should work pretty good (if the underlying interfaces weren't horribly overbuffired) in that direction. I'm looking forward to some measurements of actual buffering at the device driver/device levels. I don't know how inbound to the handset is managed via LTE. Still quite a few assumptions left to smash in the above. ... in the home router case.... ... When there are artificial rate limits in play (in, for example, a cable modem/CMTS, hooked up via gigE yet rate limiting to 24up/4mbit down), then a rate limiter (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. I'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 the load. It needent send that much data very often, to come up with a stable result.... 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 some samples into a a soft(er) rate limiter that would keep control of the 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 certainly it's too painful and inaccurate to merely measure the bandwidth once, then set a hard rate, when So far as I know the gargoyle project was experimenting with this approach. A problem is in places that connect more 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. Where will it get that from the 4G or 3G uplink? > > > > -----Original Message----- > From: "Maciej Soltysiak" > Sent: Thursday, February 28, 2013 1:03pm > To: cerowrt-devel@lists.bufferbloat.net > Subject: [Cerowrt-devel] Google working on experimental 3.8 Linux kernel > for Android > > Hiya, > Looks like Google's experimenting with 3.8 for Android: > https://android.googlesource.com/kernel/common/+/experimental/android-3.8 > Sounds great if this means they will utilize fq_codel, TFO, BQL, etc. > 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+ > Phoronix coverage: > http://www.phoronix.com/scan.php?page=3Dnews_item&px=3DMTMxMzc > Their 3.8 changelog: > https://android.googlesource.com/kernel/common/+log/experimental/android-= 3.8 > Regards, > Maciej > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --90e6ba3fd72dfa318e04d6cd9ee7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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

Doesn't = fq_codel need an estimate of link capacity?=A0


No, it just measures delay. Since so far as I know the outg= oing portion of LTE is not soft-rate limited, but sensitive to the actual a= vailable link bandwidth, fq_codel should work pretty good (if the underlyin= g interfaces weren't horribly overbuffired) in that direction.

I'm looking forward to some measurements of actual = buffering at the device driver/device levels.

I do= n't know how inbound to the handset is managed via LTE.

Still quite a few assumptions left to smash in the above.
<= div>
...

in the home router case....=

...

When there are artif= icial rate limits in play (in, for example, a cable modem/CMTS, hooked up v= ia gigE yet rate limiting to 24up/4mbit down), then a rate limiter (tbf,htb= ,hfsc) needs to be applied locally to move that rate limiter/queue manageme= nt into the local device, se we can manage it better.

I'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....

You've described one soft-rate sensing scheme (pigg= ybacking on TCP), and I've thought up a few others, that could feed bac= k from a daemon some samples into a a soft(er) rate limiter that would keep= control of the 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 certainly it's too painful and inaccurate to merely me= asure the bandwidth once, then set a hard rate, when=A0

So far as I know the gargoyle project was experimenting= with this approach.=A0
=A0
A problem is in places that= connect more than one device to the cable modem... then you end up with th= ose needing to communicate their perception of the actual bandwidth beyond = the link.=A0

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

=A0

-----Original Message-----
From: "M= aciej Soltysiak" <maciej@soltysiak.com>
Sent: Thursday, February 28, 2013 = 1:03pm
To: cerowrt-devel@lists.bufferbloat.net
Subject: [Cerowrt-devel] Googl= e working on experimental 3.8 Linux kernel for Android

Hiya,
Looks like Google's experimenting with 3.8 for Android: https://android.googlesource.com/kernel/common/+/experim= ental/android-3.8
Sounds great if this means they will utilize fq_codel, TFO, BQL, etc.<= /div>
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=A0or at least 3.3+
Regards,
Maciej

______________________________________________= _
Cerowrt-devel mailing list
Cerowrt-devel@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel




--
Dave T= =E4ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cer= owrt/subscribe.html=20 --90e6ba3fd72dfa318e04d6cd9ee7--