We have a wifi multicast application that needs to transmit multicast packet to a large number of associated clients. This multicast traffic will be the only traffic on the network.
We need to know how my devices (smart phones, mostly) can associate with a Mikrotik AP.
Many threads exist on this forum with a similar-sounding theme, but those posts are really looked for bandwidth limits. We have
no bandwidth limit. If we send multicast packets at 4 Mbits/second, the number of clients will have no effect on the router’s performance.
What we are looking for is the maximum number of devices that can associate with the AP, without considering bandwidth issues.
I know there is an absolute upper limit of 2007, which is based on the number of bits available in the TIM field of the beacon frames. I am trying to find out if some other resource may limit this number further.
I’d like to see a number like 1000 clients, all quietly receiving my multicast packets.
I’m currently using RB52Hn and RB R2n radios. I asked ubiquiti this question, and their support folks were unable to answer it.
What i found, when using 802.11 the max users capable of using a AP is around 30, can push a bit more. With NV2 this increased dramatically and depending on the ping times you would probably be able to do 60 users, maybe a bit more. This is for normal WIFI usage. Multicast should eliminate the bandwidth problem, however each user still has to access the AP, where you would probably run into trouble.
Each user does indeed have to access the AP, but they do this only once, when they associate. Once they are associated with the AP, there is no further interaction between the client and the AP, in my application, and so this should not be a limitation.
Limitations might show up as table size limits in the radio card itself or in ROS. I’m somewhat encouraged about the ROS side, since ROS defaults to a limit of 2007 users. I’m hoping they wouldn’t have done this if ROS couldn’t accommodate that many associated clients.
I am not up on multicasting, so I’ll gladly accept correction if I’m wrong, but you still have to deal with TCP/IP’s chattiness, everything that is sent is verified, acknowledged, etc, as in if you have a 10Mb download but only 128k up, you’ll never download at 10Mb.
On that note, I think you will still be limited, maybe double the normal number of clients that we generally see, but just the general network chatter between 100 clients will be quite a bit of data.
Oldman: Thanks for your comment. You are absolutely right about TCP/IP using up bandwidth for acknowledgement packets.
However, multicast doesn’t use TCP.
Since there is no way of knowing how many clients are listening, multicast always uses UDP, which does not require an acknowledging packet from the receiver back to the sender.
Because multicast uses UDP, there is no limit to the number of listeners on a network. All each client needs is an IP address, which it gets with DHCP in my application. Then, all clients just quietly wait and listen, never sending anything back to the AP.
So, still looking for someone with detailed knowledge of the inner workings of ROS and the R52Hn and R2n radio cards.
Any Mikrotik people reading this, please feel free to comment (Normis?).
NV2 is out of question since the smartphones will not support it. It is mikrotik proprietory.
Chattiness between clients can be dropped by having an access list and switching off default forward.
As per bandwidth limit and routerboard I guess RB800 with R52Hn should easily take up more than 1000. Depends on the amount of traffic each user is taking and the bandwidth limitation on the ether port of the RB being 100 mbps. Dunno if their is a Gigabit model on a similar board supporting a mini PCI for wireless. You can always have multiple RB800’s if the requirement is more.
Regards,
If the AP is essentially broadcasting UDP to The Universe at 4Mbps, it seems to me the data itself would not be the limiting factor (and a 100Mbps ether port would be more than sufficient). Rather, the bottleneck would be whatever overhead is involved in keeping the various radios associated with each other. Depending on how much (if any*) CPU that task consumes, an RB800 might be serious overkill.