[plug] Wireless-N router for faster wireless....

[Daniel Pittman]

William Kenworthy <billk at iinet.net.au> writes:
> On Tue, 2009-01-20 at 15:27 +1100, Daniel Pittman wrote:
>> William Kenworthy <billk at iinet.net.au> writes:
>> 
>> > Yes, you have to separate the bandwidth - if you have two groups of
>> > machines on different channels, you will need to bridge them - I think
>> > upnp needs to be on the same subnet.  2nd cheap access point may be
>> > the way to go?
>> >
>> > Also, if you can design it to be a totally isolated link, you might be
>> > able to turn off WPA and gain quite a lot of bandwidth.
>> 
>> What?  Can you back up that assertion?  WPA should have *no* effect on
>> available bandwidth, in general.
>> 
>> Some specific hardware may not perform well, but that is more an issue
>> with the encryption algorithm than WPA itself — especially since TKIP
>> uses the WEP algorithm, rekeyed automatically.
>> 
>> Specifically, some hardware may fall back to software / firmware when
>> using AES encryption with WPA2, but none of it should show any
>> significant degradation when running TKIP.
>
> Encryption has overhead which can drastically cut into the available
> throughput.

Do you mean on the NIC or as part of the "wire" 802.11 protocol?

> Further, cheaper 802.11 devices (mainly older ones Ive looked at) can
> get cpu bound (or results that look like that) that also seem to cut
> throughput.

Using TKIP or AES encryption?  WPA1, WPA2, personal or enterprise?

> These issues (the available embedded cpu's at the time) were why WEP
> was originally specified, even though they new it was weak even as the
> standard was ratified.

Yes.  On the other hand, here we are some 12 years later, in which time
the processing capabilities of embedded chips have ... expanded
somewhat.

So, are you asserting that most, or even many, modern wireless chipsets
are still restricted by CPU power for the embedded device when running
WEP encrypted traffic?

Regards,
        Daniel