Correct me if I'm wrong (no big leap in logic there) but it seems as
though you are discussing more theoretical connections, even if you
actually were generating connections. I mean, 253 real world users
actually attempting to use the net at the same time? No hidden node
problems? No extremely high collisions? All this without polling software?
I have. It can be simulated by randomizing the clients MAC address
(BSSID) which simulates multiple client connections. Most of the
older cheapo access points and wireless routers barf at 32 MAC
addresses total (including the access point itself). One piece of
junk firmware would only do 8 MAC addresses until it was finally fixed
just before the product was killed. A few will do about 50 addresses
for some unknown reason. If you have a limited range of DHCP
assignable IP addresses, most routers will allocate as many IP
addresses as available, and then refuse to associate or to issue any
more IP's until either reset or DHCP times out. Some current access
points, such as the WRT54G and WAP54G will do 253 clients. The WRK54G
is a stripped down version of the WRT54G and should have similar
The Proxim, Orinico, Avaya, Wavelan, Agere, Lucent, whatever access
points will do 1024 or 2048 depending one whether it's a 1 or 2 card
access point. More important, they seem to have a functional "least
recently used" algorithm for expiring stale associations and DHCP
entries. I couldn't hang or kill any of these I tested. However, I
did manage to screw up the DHCP server and where it would not give out
any more IP addresses until table entries were available. This seemed
to be timer based, were nothing would happen for about 10
minutes(???), and then a huge number of IP addresses were suddenly
available. This is not a problem as the probability of having 1024
users simultaneously try to associate is rather limited.
For reference, the 253 comes from:
The maximum addresses available is 256 (.0 thru .255). .255 is used
as the broadcast address. .0 is the entire network and not useable.
..1 is usually the access point itself.
256 - 3 = 253
Now, if you want some fun, setup the range of DHCP assignable IP
addresses to cover the entire .0 thru .255 range and start consuming
DHCP assignable IP addresses. For a while, one vendors firmware would
merrily pass out .0 .255 and the address of the access point when it
ran out of IP addresses. This was fixed but only after various hot
spot operators ran into the problem as they really might have over 253
potential users in crowded conventions, ball parks, and such.
I was generating 253 simulated connections (associations) with
corresponding DHCP delivered IP addresses. However, there was only
traffic from one IP address at a time. That's not a very realistic
test for real world conditions. Conventional wisdom and rule of thumb
is that the average WISP access point can handle per channel:
100 casual users checking email and light web browsing.
10 business users doing whatever business users do.
1 teenage Napster/Kazaa/Bearshare/Morpheus/whatever user.
As you may notice, it's not the number of connections, but what
they're doing (i.e. traffic pattern).
I've done traffic load tests in a laboratory environment using about
40 computahs. It was quite a mess and I spent much of my time dealing
with issues that had nothing to do with wireless loading. The plan
was to optimize some timing, flow control, and retrans algorithms. I
spent the first hour dealing with two of the machines that apparently
had a worm and were generating lots of junk traffic. The next hour
was spent changing the SSID to something that wasn't duplicated
elsewhere in the lab. Another 30 minutes or so was spend disarming
the screen blankers and power save features that kept shutting down
the laptops and PC's at inconvenient times. This type on nonsense
went on all afternoon. I finally got about 2 hours of testing done.
Not enough to do a decent job, but enough to check for obvious
problems. No real problems. Bandwidth distributed itself equally
between active computahs as expected.
I also got the chance to test the effectiveness of CTS/RTS flow
control. Didn't make any difference in aggregate thruput since there
were no hidden nodes in the lab. Everyone could hear everyone else so
there were no collisions. So much for that test.
I once did some modeling to see at what point polling (i.e. Karlnet
TurboCell, 802.11e (draft spec), 802.11 PCF (point coordination
function, etc) schemes were beneficial. My seat of the pants
guess(tm) is that about when about 20% of the active clients qualify
as hidden nodes, polling is highly beneficial. It doesn't take many
collisions to screw things up. Probably somewhat beneficial at
smaller number of hidden nodes. In general, outdoor networks should
use polling (or flow control) while indoor networks can get away with
CSMA/CA. For point to multipoint, where the clients all have
directional antennas, flow control is manditory and polling is highly
benificial, since none of the clients can hear any of the other