From: Dave Taht <dave.taht@gmail.com>
To: dpreed@reed.com
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Google working on experimental 3.8 Linux kernel for Android
Date: Thu, 28 Feb 2013 14:08:50 -0500 [thread overview]
Message-ID: <CAA93jw4zz3p03H_gbDSXtFzYoybRe-pWk_9xRqfRY4_wrmB-jQ@mail.gmail.com> (raw)
In-Reply-To: <1362077845.101114942@apps.rackspace.com>
[-- Attachment #1: Type: text/plain, Size: 3206 bytes --]
On Thu, Feb 28, 2013 at 1:57 PM, <dpreed@reed.com> 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" <maciej@soltysiak.com>
> 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=news_item&px=MTMxMzc
> 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
>
>
--
Dave Täht
Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
[-- Attachment #2: Type: text/html, Size: 4956 bytes --]
next prev parent reply other threads:[~2013-02-28 19:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-28 18:03 Maciej Soltysiak
2013-02-28 18:57 ` dpreed
2013-02-28 19:08 ` Dave Taht [this message]
2013-02-28 20:03 ` Jim Gettys
2013-02-28 20:58 ` dpreed
2013-02-28 21:02 ` Jim Gettys
2013-02-28 21:10 ` dpreed
2013-03-01 8:00 ` Ketan Kulkarni
2013-03-01 15:40 ` dpreed
2013-03-01 16:09 ` Jim Gettys
2013-03-01 16:27 ` dpreed
2013-03-02 3:39 ` Ketan Kulkarni
2013-03-02 13:27 ` William Allen Simpson
2013-03-02 14:20 ` dpreed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93jw4zz3p03H_gbDSXtFzYoybRe-pWk_9xRqfRY4_wrmB-jQ@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dpreed@reed.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox