[plug] Wireless-N router for faster wireless....
William Kenworthy
billk at iinet.net.au
Tue Jan 20 14:31:21 WST 2009
You use google just the same as I can ... or can you?
BillK
On Tue, 2009-01-20 at 16:29 +1100, Daniel Pittman wrote:
> 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
> _______________________________________________
> PLUG discussion list: plug at plug.org.au
> http://www.plug.org.au/mailman/listinfo/plug
> Committee e-mail: committee at plug.linux.org.au
--
William Kenworthy <billk at iinet.net.au>
Home in Perth!
More information about the plug
mailing list