From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (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 193E3200373 for ; Thu, 8 Dec 2011 04:25:06 -0800 (PST) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id pB8CP4fr021387; Thu, 8 Dec 2011 04:25:04 -0800 Date: Thu, 8 Dec 2011 04:25:04 -0800 (PST) From: david@lang.hm X-X-Sender: dlang@asgard.lang.hm To: Dave Taht In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Coping with wireless-n [#305] X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 12:25:06 -0000 On Thu, 8 Dec 2011, Dave Taht wrote: > On Thu, Dec 8, 2011 at 12:51 PM, wrote: >> On Thu, 8 Dec 2011, Dave Taht wrote: > >> this puzzles me. >> >> splitting 2.4G and 5G into different different networks (broadcast domains) >> is a huge win. cince I can't find any open implementation fo band steering, >> this requires putting the two bands on different SSIDs. > > Oh, god no, I'm not dropping that. Having those split AND off the wired > network is staying in... > >> but I don't understand why there is a big problem with G and N sharing the >> same SSID. > > Because you can fully FQ G, and if you do that to N, it messes up aggregation. I don't recognize the term "FQ". when you say it messes up aggregation, do you mean combining two channels togeather for higher throughput or something else? I was assuming that if you are running a mized network you only use a single channel for N. If you are using multiple channels for N they should be a separate SSID, just from the fact that you are using two channels for N but only one for G (which one would be the question) >> >> there is some > > Some? some, but it's an unavoidable feature of wireless communication. You can consider turning off some modulation types, but since the clients automatically fall back to slower modulation types when there is a problem, the result will be failed connections. now, this may still be the right thing to do, because the failback to a slower modulation type works well for weak signal situations, but in a high density situation (which is basically every 2.4G deployment in the real world nowdays), taking longer to send the same data just means that you are more vunerable to another transmitter clobbering you, so it actually decreases reliability. David Lang >> grief with having different speeds on the same channel, but >> only in that the same amount of data will take longer to transmit (causing >> problems with predicting how long the queue is in terms of time as it will >> vary on the destintation), but even if you stick with G for example, it can >> transmit at 54, 48, 36, 24, 18, 12, 6, 1 Mb/s. adding N just adds some >> higher speeds to this. If the devices are configured sanely, they should be >> transmitting the header for a G frame to reserve the air time and then >> sending the N frame inside of that. this has a slight overhead compared to a >> pure N network, but it doesn't matter if the G network is on the same SSID >> or on a different one, the problem is sharing the airtime on the channel. > > It's a packet scheduler test more than anything else. > >> David Lang > > > >