Re: Big Temporary Networks
----- Original Message -----
From: "Gaurab Raj Upadhaya" <gaurab@lahai.com>
So you're *REALLY* motivated on this "reduce the coverage" thing, then.
you could say yes :), reduce the coverage per-AP. Most APs I have seen will start failing with about ~100 associations and not to forget about the max GE uplink they have. that's about 40-50 people at most (being optimist).
Really? 100 associations? On enterprise/carrier grade gear? Seriously?
g) we have a /32 and /20 (v6 and v4 respectively) address space assigned by APNIC for this and other events in Asia (including the APNIC meeting itself) so we use that. We used to have a v4 /16 though before runout.
I'm talking to someone from the Interop team; they have a dedicated /8.
They gave that 45/8 back and kept 2 x /16 for themselves.
I did not know that. Good on 'em. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On 9/16/12 9:24 AM, Jay Ashworth wrote:
----- Original Message -----
From: "Gaurab Raj Upadhaya" <gaurab@lahai.com>
So you're *REALLY* motivated on this "reduce the coverage" thing, then. you could say yes :), reduce the coverage per-AP. Most APs I have seen will start failing with about ~100 associations and not to forget about the max GE uplink they have. that's about 40-50 people at most (being optimist). Really? 100 associations? On enterprise/carrier grade gear?
Seriously? We tend to engineer for a maximum of around 50 associations per radio (not AP). beyond that performance really starts to suck which can be measured along a multitude of dimensions. The most visible one to the client(s) being latency due to loss and subsequent retransmission.
Reduction in coverage is done on a couple of dimensions. that ap with the 3-5dBi gain dipoles probably shouldn't be 100mW. but the noise floor is in a different place when the room is full of clients so it can't be to low either. Dropping the low speed rates backward compatibility with 802.11b and setting the multicast rate to something higher will force clients in marginal coverage situations to roam more quickly, hog the air less and allow for higher throughput.
g) we have a /32 and /20 (v6 and v4 respectively) address space assigned by APNIC for this and other events in Asia (including the APNIC meeting itself) so we use that. We used to have a v4 /16 though before runout. I'm talking to someone from the Interop team; they have a dedicated /8. They gave that 45/8 back and kept 2 x /16 for themselves. I did not know that. Good on 'em.
Cheers, -- jra
* joelja@bogus.com (joel jaeggli) [Sun 16 Sep 2012, 18:42 CEST]:
We tend to engineer for a maximum of around 50 associations per radio (not AP). beyond that performance really starts to suck which can be measured along a multitude of dimensions. The most visible one to the client(s) being latency due to loss and subsequent retransmission.
Reduction in coverage is done on a couple of dimensions. that ap with the 3-5dBi gain dipoles probably shouldn't be 100mW. but the noise floor is in a different place when the room is full of clients so it can't be to low either. Dropping the low speed rates backward compatibility with 802.11b and setting the multicast rate to something higher will force clients in marginal coverage situations to roam more quickly, hog the air less and allow for higher throughput.
This is all good advice that you should implement. The difficulty with high user density deployments is getting stations to associate to the nearest access point on the optimal band. When presented with the same SSID for 2.4 and 5 GHz, clients usually prefer te 2.4 GHz one because its S:N ratio usually seems better (inherent to the lower frequency). However, in practice this isn't always the case as there usually are many more clients on 2.4. Various vendors of lighweight access points use tricks to get clients to associate on the 5 GHz band: e.g. Cisco, I think, will reject an initial association request at 2.4 GHz in the hope that the client will retry at 5 GHz before retrying at 2.4, which will both be accepted. -- Niels.
participants (3)
-
Jay Ashworth -
joel jaeggli -
Niels Bakker