Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Which characteristics should I look for in a wireless access point slated to connect 50 devices for peer-to-peer communication? My largest concern is that all devices maintain a reliable connection and deliver packets dependably.

My requirements:

  • 1 large room with few obstructions
  • 100KB/s throughput per device, simultaneous with all devices
  • Reliable wi-fi connection (send failure pauses the entire app until all devices catch up).
  • Mixed 802.11 g/n

When one device publishes information, a large subset of all other devices receive it immediately. The information is typically 10KB to 100KB. Publications across all devices peak at 5 per second.

share|improve this question
So, just to be perfectly clear, are you saying that even when all 50 clients are operating, the peak per-second load for the whole network would be 5 * 100 KibiBytes = 500 KibiBytes = 4.096 megabits? – Spiff Oct 3 '13 at 20:36
No. Consider 5 simultaneous publishes with 100% coverage to all clients (worst case). Write to other clients is (5 publishers) * (50 clients) * 100KB/s = 25,000KB/s. In practice, total throughput is closer to 5,000KB/s under high use because publication does not overlap. – Chris Betti Oct 3 '13 at 22:24
Okay, I may need to re-write my answer based on that information. So it sounds like you're doing separate unicasts from each publisher to each that correct? – Spiff Oct 3 '13 at 22:40
That's correct. Follow-up provided on your answer. – Chris Betti Oct 3 '13 at 22:43

[Disclaimer, I wrote this Answer before getting a clarification above. I'll need to re-write this Answer based on my better understanding, but for now I'm leaving it as-is in case it helps someone else who's designing a Wi-Fi network for a 50-peer multicast protocol.]

Beware that multicasts/broadcasts and Wi-Fi don't mix

This probably isn't the Answer you were looking for, but it's probably the most important thing you need to consider.

On wired Ethernet, especially with switches, multicasts were less costly than separate unicasts. But on wireless Ethernet (Wi-Fi), multicasts and broadcasts don't get link-layer Acknowledgements, because that would cause an Ack storm for each multicast that would be hard to deal with. So multicasts have to be sent at a low enough data rate that every client of that AP will be sure to receive them reliably (lower rates are generally simpler modulations that are more reliably received at longer range or in noisier environments). This means that a multicast packet will tend to take up many times more airtime (bandwidth) than a unicast packet of the same size.

It's pretty common for a 2.4GHz Wi-Fi AP to send multicasts at the 1 megabit/sec data rate by default. If I understood your bandwidth requirements correctly, that would be slightly less than one-quarter of the bandwidth your protocol requires (assuming your protocol uses multicast, which it sounds like it probably does).

So you'd need to make sure you configure your AP to use at least the 5.5 mbps rate, or probably higher, when sending multicasts. You'd also need to make sure that all of your devices are in range to receiver that data rate reliably (probably not hard in one large-but-not-huge room with no obstructions).

Oops, I almost forgot to account for Intra-BSS Relay. When using Wi-Fi with an AP (as opposed to "IBSS" a.k.a. "Ad-hoc" mode), the AP relays all transmissions from one wireless client to another. This allows the network to cover a wider area, as clients don't need to all be in range of each other, they just each need to be in range of the AP. So your 4+ mbps of data is going to be sent at a unicast data rate from the sending client to the AP, and then relayed by the AP at the multicast rate. So if during one peak one-second period, the clients sending each of the five 100 KibiByte transmissions all happen to be on the edge of the network where they can only maintain the 5.5 megabit per second data rate, that means that it would take almost two full seconds to get all of that "one-peak-second's worth" of date multicasted out to all of the clients. So, yeah, the 5.5 mbps data rate isn't going to work for you either. Shoot for the 12 mbps data rate as your multicast rate, and make sure all of your clients are "within 12mbps range" so to speak.

So, make sure your Wi-Fi lets you set what rate multicasts are sent at. Some APs let you set this explicitly, whereas others may derive the multicast rate from other settings. For example, if it lets you set the Basic Rates (i.e. required rates), it may pick the lowest Basic Rate for the multicast rate. Or if it lets you disable 802.11b rates, it may pick the lowest G rate (6mbps) as the multicast rate. Apple's APs tend to let you set the multicast rate by an obscure low/medium/high rubric, for which there's a decoder table here: How To Set Multicast Rate On Apple AirPort Extreme

Other things to think about:

  • Make sure your application-layer protocol is handling the need for retransmissions, since multicasts over Wi-Fi are not guaranteed to be reliable. Take your average retransmission rate into account when calculating your bandwidth (and thus multicast rate) needs.

  • Make sure you use a clean channel. My multicast rate calculations assumed a perfectly clean channel. If other nearby users are keeping the channel busy, say, half the time, then you'd need to at least double the multicast rate from what I'd previously calculated..

  • Some older APs that advertised a 50 client limit did so because their hardware had a limit to how many separate per-client unicast keys they could keep track of. Some had a hard limit there, but others used software to handle more keys than could be handled in hardware, but took a small performance hit for it. Probably not a problem in your situation, but if you have any problem with getting 50 clients on at the same time, and you started out with WPA2 (or WPA) enabled, try it without any wireless security enabled instead.

  • If you require WPA2 (or WPA) security, try to keep the client devices from going into system sleep or otherwise leaving the network. Every time a client leaves, the group key (the one for encrypting multicast/broadcast packets) must be changed. This takes a flurry of network activity, which would eat into the airtime you have available for your multicasts. It also delays all further multicasts until all the remaining clients have confirmed receipt of the new group key, and will cause the AP to disconnect any clients that failed to confirm receipt of the new group key. Which will cause more small flurries of activity as those castaway clients get back onto the network.

share|improve this answer
Very thorough Spiff. While the app is a candidate for multicast, I haven't yet evaluated it (your input will be extremely helpful). At this time we're using a pub/sub unicast messaging service. Would unicast merely double, or significantly increase, your per-device bandwidth estimates? – Chris Betti Oct 3 '13 at 22:42

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.