From: david@lang.hm
To: Dave Taht <dave.taht@gmail.com>
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Coping with wireless-n [#305]
Date: Thu, 8 Dec 2011 04:25:04 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.02.1112080418590.2347@asgard.lang.hm> (raw)
In-Reply-To: <CAA93jw7vMYWFcXDLNOGQ3fGSRsE0gK9ErNVc67F13LApY5=qkQ@mail.gmail.com>
On Thu, 8 Dec 2011, Dave Taht wrote:
> On Thu, Dec 8, 2011 at 12:51 PM, <david@lang.hm> 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
>
>
>
>
next prev parent reply other threads:[~2011-12-08 12:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-08 8:20 Dave Taht
2011-12-08 11:51 ` david
2011-12-08 12:09 ` Dave Taht
2011-12-08 12:25 ` david [this message]
2011-12-08 12:46 ` Dave Taht
2011-12-08 12:48 ` Dave Taht
2011-12-08 13:16 ` david
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.02.1112080418590.2347@asgard.lang.hm \
--to=david@lang.hm \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox