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

[david at lang.hm]

On Thu, 8 Dec 2011, Dave Taht wrote:

> This is the 6th in a series of mails doing a post-mortem and rethink
> of what is in cerowrt.
>
> Basically I think the 2.4ghz spectrum is beyond hope. Everywhere I've
> been there are dozens of radios all on all the channels available, all
> competing, all interfering, and the difference in performance results
> I get minute to minute, hour to hour varies so wildly that in order to
> get a good picture of how basic 2.4ghz performance worked I had to go
> to remote valley in france where there was no competing signals to
> deal with.
>
> There I got pretty equivalent results between 2.4ghz and 5. The rest
> of the time, not so much.
>
> As for wireless-g vs n, the current architecture of the mac80211 stack
> buries packet aggregation so deeply within it that the two
> technologies are very incompatible. It also bothers me that management
> frames are buried so deeply, too.
>
> The only places I've been this year that had a functional wireless
> network, rigorously divided up the SSIDs into g, n, ipv4 and ipv6
> specific parts, and were using Cisco hardware.
>
> I don't see the need to have separate SSIDs for 4 and 6, but I think
> g+QFQ, and n+SFQ might do better in the general case on an AP.
>
> QFQ would work well on client machines, particularly with n, to break
> up packet bursts more sanely into multiple streams. SFQ, less so. I'd
> rather pursue QFQ on the clients as it better 'shreds' competing
> bursts. I'd like others to play with it too.
>
> and in all cases getting to where something BQL-like + Time in Queue
> on top of those two techniques will help most of all,
> but better feedback loops and means of determining bandwidth
> differences between destinations are kind of required.
>
> And doing MUCH better classification into the hardware queues would be
> good, too.
>
> So in the next release of cerowrt I'm planning on having a separate
> n-only or g-only SSID available on the 5ghz channel, and
> to experiment with the above qdiscs. I sort of have some major ANT and
> DSCP specific classifier code that I plan to polish up.
>
> as for BQL and Time in Queue, that work is only just beginning and I
> hope to track it closely.  As to how to make it apply to wireless,
> I look forward to the engineering debate(s). It's a ton of work.

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.

but I don't understand why there is a big problem with G and N sharing the 
same SSID.

there is some 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.

David Lang