From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 770F121F184 for ; Tue, 8 Oct 2013 04:00:05 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id hz10so3463632vcb.40 for ; Tue, 08 Oct 2013 04:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZL9MijkgPXeNsEI49gcnSVog/sXUZS9AwKPSVcuVhfk=; b=caDz0UyMaz/z4cOlAnLhuUYgKdD7EnOCt053nBMmH3tmyX5X2z5iQns63YK5B4Lfmw PQEfzySBs8L1Yvn7nm5p8oEXF5Hlh4y4sLU+YASyjjbg91KYnY922kU8wOk+GzFKE2vZ HH5FfBbhfTR3n18Sn26vEeaeDZVOGCRxQevfh58hFA1zACyptIgzS8Bjqtu1nCa1Rh4x AfxZy9f9LrCHOuHg6CBd0r2BZsMu0aXiDtjcxvxpTvUmaf6KIL3nMMA39jnJQqFh7aS/ +38T7cqEYHZs21yT08vqGn1z35L5EHJEh6Qe9rBiC50XSCoryDowkv927sxgwdWskxxi G39A== MIME-Version: 1.0 X-Received: by 10.52.118.73 with SMTP id kk9mr466543vdb.13.1381230004069; Tue, 08 Oct 2013 04:00:04 -0700 (PDT) Received: by 10.52.74.137 with HTTP; Tue, 8 Oct 2013 04:00:03 -0700 (PDT) In-Reply-To: <5251D038.9030306@superduper.net> References: <5250DB8F.4060004@superduper.net> <52517B63.1060705@superduper.net> <5251D038.9030306@superduper.net> Date: Tue, 8 Oct 2013 07:00:03 -0400 Message-ID: Subject: Re: Enabling Byte Queue Limits in the ath5k wireless driver From: Anirudh Sivaraman To: Simon Barber Content-Type: text/plain; charset=UTF-8 Cc: bloat-devel@lists.bufferbloat.net X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 11:00:05 -0000 On Sun, Oct 6, 2013 at 5:03 PM, Simon Barber wrote: > Indeed - but this is based on underruns while there is more to send - once > it has established a length that does a good job of keeping the hardware fed > it should not change much. This control loop will slowly catch up with the > different speeds wireless packets are sent at (if a single link is in use, > not multiple links) but it would be better controlled and also handle > multiple links on one interface (e.g. Access point mode, or 11z) properly if > packet duration was considered. > Ok, that makes a lot of sense. I guess I 'll try implementing BQL first, followed by TQL, and see what I find. Anirudh > Simon > > > On 10/6/2013 9:36 AM, Anirudh Sivaraman wrote: >> >> On Sun, Oct 6, 2013 at 11:01 AM, Simon Barber >> wrote: >>> >>> BQL or TQL are open-loop - there is no feedback. The amount of bytes or >>> total packet transmission time in the queue is counted when packets enter >>> and leave the queue, and a hard limit of total bytes or total time in >>> queue >>> is set. When I say time - I mean that on a packet entering the queue the >>> total time the packet will take to transmit is calculated, and that time >>> is >>> added to a count to the total time currently in queue. When a packet has >>> been transmitted the time is subtracted from the total time in queue. >>> There >>> would be no interference with CODEL running in front of this. >>> >> I thought, based on http://lwn.net/Articles/454390/, that the queue >> length is dynamically adjusted by DQL/BQL/TQL. This is the device >> driver control loop I was referring to. This queue length in turn >> dictates when the dequeue function is called at the qdisc layer, where >> CoDel is running. Please correct me if I am wrong here. >> >> Anirudh >> >>> Simon >>> >>> >>> On 10/6/2013 6:31 AM, Anirudh Sivaraman wrote: >>>> >>>> On Sat, Oct 5, 2013 at 11:39 PM, Simon Barber >>>> 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 >>> >>> >