From: Dave Taht <dave.taht@gmail.com>
To: David Reed <dpreed@reed.com>
Cc: make-wifi-fast@lists.bufferbloat.net,
Andrew McGregor <andrewmcgr@gmail.com>
Subject: Re: [Make-wifi-fast] thoughts on rate control optimizations for less than perfection?
Date: Thu, 31 Mar 2016 18:05:20 -0700 [thread overview]
Message-ID: <CAA93jw5umi+dohvv+oitLmRMTXi-v0r3SCv9r9pjnz8HRVeN1g@mail.gmail.com> (raw)
In-Reply-To: <1459376200.475225876@apps.rackspace.com>
On Wed, Mar 30, 2016 at 3:16 PM, <dpreed@reed.com> wrote:
> Nice piece.
THX!
What I needed to do was start writing more things down, after having
total writers block with trying an "academic voice". As my natural
métier is code, email, and rants^H^H^H^Hblogs, I figure getting a
rough draft out in my natural voice, with logbook data to back it up,
would be better (and somewhat more entertaining) than what I've been
doing. Can always rewrite later.
I could (now that it's out of my system) cut that entire first set of
paragraphs out, and mention a few other possibilities in coupling rate
control to a desirable loss rate. Or I (or you!) could go back an
reminiscence about those bad ole mosquitonet days 92-99 where the loss
was so bad that nothing worked and yet a retry at the mac layer was
considered utter heresy... or...
> But I would be relentless about simplifying mechanisms and not having lots of options to achieve the same goal. That way lies non-interoperability (just as ECN ended up being pretty non-interoperable in a world where everyone gets to choose a different way to try to use it)
I hear ya. The biggest problem remains binary blob firmware, although
it looks like both the qca team and intel are grokking things more
deeply now and might start providing the right hooks, once we figure
out what they are. Michal is off rigorously exploring dql options, I'm
trying to get the right sort of hardware to catch up, and/or applying
similar stuff to ath9k....
>
>
>
> On Tuesday, March 29, 2016 3:48pm, "Dave Taht" <dave.taht@gmail.com> said:
>
>> I wish I could remember where the selective unprotect idea came from....
>>
>> see: http://blog.cerowrt.org/post/selective_unprotect/
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>
>
>
prev parent reply other threads:[~2016-04-01 1:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-29 19:48 Dave Taht
2016-03-30 22:16 ` dpreed
2016-04-01 1:05 ` Dave Taht [this message]
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/make-wifi-fast.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93jw5umi+dohvv+oitLmRMTXi-v0r3SCv9r9pjnz8HRVeN1g@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=andrewmcgr@gmail.com \
--cc=dpreed@reed.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
/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