[Cerowrt-devel] Coping with wireless-n [#305]

[Dave Taht]

On Thu, Dec 8, 2011 at 1:25 PM,  <david at lang.hm> wrote:
> On Thu, 8 Dec 2011, Dave Taht wrote:
>
>> On Thu, Dec 8, 2011 at 12:51 PM,  <david at 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".

Fair Queue

http://info.iet.unipi.it/~luigi/qfq/ in this case.

>
> when you say it messes up aggregation, do you mean combining two channels
> 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 wireless
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 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)

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 problem,
> the result will be failed connections.

To give you an idea, at 5ghz I'm capable with cerowrt at achieving 150Mbits
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 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.

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, 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
>>
>>
>>
>>
>>
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net