From: d@taht.net (Dave Täht)
To: bloat-devel <bloat-devel@lists.bufferbloat.net>,
bloat@lists.bufferbloat.net
Subject: Bufferbloat related patches for the iwl3945
Date: Sun, 13 Feb 2011 13:22:27 -0700 [thread overview]
Message-ID: <871v3br8fw.fsf_-_@cruithne.co.teklibre.org> (raw)
In-Reply-To: <AANLkTik-nK+OaL4vBns8bcJq6QoGL9ohiZ1s=RTQrdrF@mail.gmail.com> (Nathaniel Smith's message of "Sun, 13 Feb 2011 10:31:44 -0800")
Nathaniel Smith beat me to posting patches this weekend. [1]
See:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/64733
For details.
Perhaps this will spark some discussion here and elsewhere.
Nathaniel Smith writes:
> Thanks for the poke. I just sent the patches.
> I guess we'll see if anyone responds this time.
>
> I actually suspect that the approach I use in the patch is wrong in
> the long run, because it needs that magic constant ("2 ms"), and even
> then it can't properly take into account task switching latency (if it
> takes >2 ms to get back to the driver, then the queue may drain and we
> may lose some throughput, but who knows whether that's the case or
> not). What would be better would be some way to detect the case where:
> -- there were packets waiting at the next level up -- that would have
> been queued, except that the driver decided that it had enough packets
> queued already -- and then the driver's queue underflowed If we had
> this information, then the driver could do a better job of tuning; it
> already can measure excess buffer capacity, and then it'd be able to
> measure insufficient capacity directly, and adjust its buffer size
> accordingly.
I think that is a good start.
>
> If the network layer just had a counter that it incremented every time
> its queue transitioned from empty to non-empty or vice-versa, then we
> could detect the above situation as: the driver's queue is empty,
> incoming packets are choked, and the counter is odd and has the same
> value as it did when we last accepted a packet. But it doesn't have
> that counter, and I didn't feel inspired to try and get changes
> accepted to the generic networking code.
>
> I think I'd better work on my thesis instead of getting involved in
> the bufferbloat list ;-), and similarly am unlikely to follow up much
> on the ideas above, but feel free to forward to anyone who might be
> interested (or to the list in general).
>
> Cheers,
> -- Nathaniel
--
Dave Taht
http://nex-6.taht.net
1: In the future I will keep code related stuff on the bloat-devel list
next parent reply other threads:[~2011-02-13 20:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87lj3hd00r.fsf@taht.net>
[not found] ` <AANLkTi=HGuVvmUFw+TWp9pbO7fAtBBb+U88_PuVW8QSZ@mail.gmail.com>
[not found] ` <874o8jlhjd.fsf@cruithne.co.teklibre.org>
[not found] ` <AANLkTik-nK+OaL4vBns8bcJq6QoGL9ohiZ1s=RTQrdrF@mail.gmail.com>
2011-02-13 20:22 ` Dave Täht [this message]
[not found] ` <87ei7bprvw.fsf@cruithne.co.teklibre.org>
[not found] ` <AANLkTik_TydO+E4NTNH9k5t59tLajDH2Qe569WWBv9HD@mail.gmail.com>
[not found] ` <8739nrpgi5.fsf@cruithne.co.teklibre.org>
[not found] ` <4D5886AA.4000906@openwrt.org>
[not found] ` <87y65jnzla.fsf@cruithne.co.teklibre.org>
2011-02-14 2:16 ` Bemused to Felix Fietkau
[not found] ` <AANLkTik7xf7kKQuTYEoEHi5Xsraw7H9WYrQ9SqKdZTM-@mail.gmail.com>
2011-02-14 17:18 ` Combating wireless bufferbloat while maximizing aggregation Dave Täht
2011-02-15 3:08 ` Bemused to Felix Fietkau
2011-02-15 6:28 ` Nathaniel Smith
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871v3br8fw.fsf_-_@cruithne.co.teklibre.org \
--to=d@taht.net \
--cc=bloat-devel@lists.bufferbloat.net \
--cc=bloat@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