From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nm29.access.bullet.mail.sp2.yahoo.com (nm29.access.bullet.mail.sp2.yahoo.com [98.139.44.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id CC7D621F0BD for ; Fri, 4 Jan 2013 13:53:08 -0800 (PST) Received: from [98.139.44.105] by nm29.access.bullet.mail.sp2.yahoo.com with NNFMP; 04 Jan 2013 21:53:06 -0000 Received: from [67.195.22.107] by tm10.access.bullet.mail.sp2.yahoo.com with NNFMP; 04 Jan 2013 21:53:06 -0000 Received: from [127.0.0.1] by smtp103.rog.mail.gq1.yahoo.com with NNFMP; 04 Jan 2013 21:53:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1357336386; bh=PUCp1/6/itBRVD4UUaZSzV+8CuIcyrksz2A68UrZim4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; b=FXvIODAGariKSu8wrk9bR08WLq2X1Hb5uKiauVapJl+L/uNfEACnQCAg6wn1Oi6Pw1jGItEmyYU2i2hKQQGDSjrS9yjCD8o6HJ6WBv6V6mxgeRHZ7YdblmwSwruTHqn2nuHA+aAk2akFRf1KvNNFOwjbGRbGA+zgZPjKvDOFWpY= X-Yahoo-Newman-Id: 171898.31434.bm@smtp103.rog.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: uBy6TIwVM1mxy5wbI.WgIObWypfpODq9TYzLeKd5YuPi2Ab KkXiynWHv2..0Y4F4wc4.nIAGhMoY.UYSVlM8IfTI0TJ_5qMUjnCjxXHg7yF hCBCgCDf60zx4guTMvuJnRTR5Kc9H1XqKGVt6zWvYGMIaHlVvTpU3bFvH6fo 6.arWBTfWQkxJsH3ZF0jrWRhbsb9Xp2Zklipwz.7SCJFR_6LhgJi0.Hkpd5n BgQaMtC0X4xIN56Djm4a6JybF248IVREcKVUN9pXXWG75Ge5_CRrOw0_XZVh UrRzytGBD5Nd5Vmw9Q5UwVAZWivcBSSLGb.Q3NVmTMYiF_vxn2BOrVqyGgIR uq.Wzabw7W3TWz.sjaAkWa37nwY_lIt3EaP57TG5tKGEeMRxeyY9sZRwyDjB W9XYw8JMaSH7P6HHtDmKCuOY0rrgRlgl2k07pJgKoN4jlhwoUMJqJVkplqwH pVdTZZbgFmoL.JP.rp42pb74t X-Yahoo-SMTP: sltvjZWswBCRD.ElTuB1l9j6s9wRYPpuyTNWOE5oEg-- Received: from [192.168.1.104] (davec-b@99.225.204.110 with plain) by smtp103.rog.mail.gq1.yahoo.com with SMTP; 04 Jan 2013 13:53:06 -0800 PST Message-ID: <50E6F076.4070403@rogers.com> Date: Fri, 04 Jan 2013 10:08:38 -0500 From: David Collier-Brown User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Bloat] wifi AP switching time X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: davecb@spamcop.net List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 21:53:09 -0000 On Jan 1, 2013 6:50 PM, "Michael Richardson" wrote: >> A comment was made a month ago or so about how long it takes wifi APs >> to switch from transmitting (unicast) to one station to another. That >> there was quite a large latency here, and that this was one reason that >> the AP designers wanted large buffers to accmulate, so that the >> switching time could be amortized over a larger number of packets. Pedro Tumusok replied > I might be way of here, but to me this sounds like a-mpdu which is used to > aggregate frames to get higher throughput. Thats in the specification, its > in 802.11ac and I believe that it go introduced with 802.11n. > > It is there to mitigate the overhead of aquiring the channel. And that in turn sounds like a place where codel may be needed to ensure the buffer drains down to nothing in the general case. Alternatively, a simpler approach might be to buffer only when actively trying a acquire a channel. I wonder if there are other only-for-one-reason buffers lying around in the communication path (;-)) --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain (416) 223-8968