Historic archive of defunct list bloat-devel@lists.bufferbloat.net
 help / color / mirror / Atom feed
From: Anirudh Sivaraman <sk.anirudh@gmail.com>
To: Simon Barber <simon@superduper.net>
Cc: bloat-devel@lists.bufferbloat.net
Subject: Re: Enabling Byte Queue Limits in the ath5k wireless driver
Date: Sun, 6 Oct 2013 09:31:57 -0400	[thread overview]
Message-ID: <CAMdC6xYLoCPTJE3sprx=kDpm0bGc_jmf41ez-1G4poMk2EHVFA@mail.gmail.com> (raw)
In-Reply-To: <5250DB8F.4060004@superduper.net>

On Sat, Oct 5, 2013 at 11:39 PM, Simon Barber <simon@superduper.net> wrote:
> BQL does make sense, but TQL would be even better - 'Time Queue Limits'.
> Which would work based on an estimate of how much time each packet will take
> to send, and limiting the hardware queue to contain a total mount of 'time'.
> The purpose of the hardware queue is to mask interrupt and other latencies
> involved in refilling an empty queue - a time based phenomenon. Hence time
> is the best metric to control it - with fixed speed interfaced like ethernet
> bytes=time, but not so on wireless.
>

Thank you for your reply. TQL does make more sense for wireless at
least. However, assuming that someone implement a qdisc like CoDel and
attaches it to the wireless interface, doesn't TQL (or for that matter
BQL) lead to two possibly competing control loops (one at the qdisc,
and one at the device driver)?

Anirudh
> Simon
>
>
> On 10/3/2013 11:49 AM, Anirudh Sivaraman wrote:
>>
>> Hi,
>>
>> I am looking into enabling BQL for the ath5k driver, and was wondering
>> if anyone here knows of any prior efforts in this direction. In
>> particular, is BQL even a sensible strategy for wireless drivers?
>> Thank you in advance for any advice you may have in this regard.
>>
>> Anirudh
>> _______________________________________________
>> Bloat-devel mailing list
>> Bloat-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat-devel
>
>
> _______________________________________________
> Bloat-devel mailing list
> Bloat-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat-devel

  reply	other threads:[~2013-10-06 13:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-03 18:49 Anirudh Sivaraman
2013-10-06  3:39 ` Simon Barber
2013-10-06 13:31   ` Anirudh Sivaraman [this message]
2013-10-06 15:01     ` Simon Barber
2013-10-06 16:36       ` Anirudh Sivaraman
2013-10-06 21:03         ` Simon Barber
2013-10-08 11:00           ` Anirudh Sivaraman

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='CAMdC6xYLoCPTJE3sprx=kDpm0bGc_jmf41ez-1G4poMk2EHVFA@mail.gmail.com' \
    --to=sk.anirudh@gmail.com \
    --cc=bloat-devel@lists.bufferbloat.net \
    --cc=simon@superduper.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