From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id C6B1F200346; Thu, 8 Dec 2011 04:48:45 -0800 (PST) Received: by iaen33 with SMTP id n33so4070051iae.16 for ; Thu, 08 Dec 2011 04:48:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zot81o9dLV76fuY/gr9fYSdUIU7JU572rMzVJc++wi0=; b=JfNZ2xzLZVND9yMn4LBfqqNcn4Io7HdvQPt1BbsHuSYCfZ5hJ1EwQ41a8l6vS3Zchg irhEr7YPzYzLhwC8oLEh8slRWfCYM/9xMCoNgHmn+o7/t5uVQdM+6me1BlyRpU3BLNzf 0I9rWgTMoTZndvOA9UAlI5HJd1pE4+GGNiZ8w= MIME-Version: 1.0 Received: by 10.50.88.135 with SMTP id bg7mr3985401igb.11.1323348525166; Thu, 08 Dec 2011 04:48:45 -0800 (PST) Received: by 10.231.204.83 with HTTP; Thu, 8 Dec 2011 04:48:45 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Dec 2011 13:48:45 +0100 Message-ID: From: Dave Taht To: david@lang.hm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: cerowrt@lists.bufferbloat.net, 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:48:46 -0000 note, that I do try on occasion to capture stuff into the bug tracker When you see something like [#305] in the subject or cerowrt ccd, it goes there... That said, I have to not surprise people with that 'feature'. On Thu, Dec 8, 2011 at 1:46 PM, Dave Taht wrote: > On Thu, Dec 8, 2011 at 1:25 PM, =A0 wrote: >> On Thu, 8 Dec 2011, Dave Taht wrote: >> >>> On Thu, Dec 8, 2011 at 12:51 PM, =A0 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". > > Fair Queue > > http://info.iet.unipi.it/~luigi/qfq/ in this case. > >> >> when you say it messes up aggregation, do you mean combining two channel= s >> togeather for higher throughput or something else? > > No, the way the driver is structured it swallows as many packets as are > aggregatable for a given destination, then ships them. If you instead > try to do the right thing - which is to break up packet bursts into > as tiny pieces as possible, aggregation goes to heck. What you want > to do is aggregate fair queued packets for a given destination, at a > size that will fit (up to 64 packets or 64kbytes) at the rate the wireles= s > interface is running at. > > As a result nobody does FQ, nor AQM, on wireless n, where it is > so desparately needed. > >> >> I was assuming that if you are running a mized network you only use a si= ngle >> 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) > > One channel for both N and G in this case. Only one radio for 5ghz. >> >>>> >>>> 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 probl= em, >> the result will be failed connections. > > To give you an idea, at 5ghz I'm capable with cerowrt at achieving 150Mbi= ts > with TCP - in the clean air here. > > At 2.4, it's rare I can get more than 20, and fairly often much less than= that. > > Any given test I run regarding wireless simply is not repeatable if I do = it > on 2.4ghz. > > I can usually 'hear' more than 30 access points at my apt, as another > example. > > >> >> 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 h= igh >> 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. > > yes, minstrel rocks. >> >> 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, i= t >>>> 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 shou= ld >>>> 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 compare= d >>>> 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 chann= el. >>> >>> >>> It's a packet scheduler test more than anything else. >>> >>>> David Lang >>> >>> >>> >>> >>> >> > > > > -- > Dave T=E4ht > SKYPE: davetaht > US Tel: 1-239-829-5608 > FR Tel: 0638645374 > http://www.bufferbloat.net --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net