From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from masada.superduper.net (unknown [IPv6:2001:ba8:1f1:f263::2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 1C8BD21F1B5 for ; Sun, 6 Oct 2013 14:04:15 -0700 (PDT) Received: from [209.104.70.126] (helo=[172.16.1.193]) by masada.superduper.net with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VSvUp-0004TQ-CS; Sun, 06 Oct 2013 22:04:12 +0100 Message-ID: <5251D038.9030306@superduper.net> Date: Sun, 06 Oct 2013 14:03:52 -0700 From: Simon Barber User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Anirudh Sivaraman Subject: Re: Enabling Byte Queue Limits in the ath5k wireless driver References: <5250DB8F.4060004@superduper.net> <52517B63.1060705@superduper.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) 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: Sun, 06 Oct 2013 21:04:15 -0000 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. 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 >>