Multicast Airtime Simulator
Why one video stream or a room of chatty devices can slow a whole Wi-Fi network: multicast airtime at the basic rate, unicast to each client, DTIM delay, and fixes such as multicast-to-unicast conversion, mDNS gateways and Proxy ARP.
How to use this tool controls and what to look for
Choose a type of traffic, then compare sending it once as multicast with sending a copy to each client. Work down the numbered cards.
Controls to change
- Traffic: choose a video stream, discovery chatter (mDNS, SSDP), ARP and other broadcasts, or push-to-talk audio.
- Stream bitrate: set how much traffic there is. Devices sending it adds more senders.
- Lowest basic rate: set the rate multicast is sent at.
- Clients receiving it: add clients and find where unicast to each one costs more than multicast.
- Where the clients are: choose All close, Mixed or One far away.
- DTIM period: change how often the AP sends held multicast when a client is asleep.
- At least one client is in power save: see the extra delay the DTIM adds.
What to look for
- Multicast goes out once, at the slowest basic rate, so one stream can take a large share of the channel.
- Unicast to each client uses fast rates, so it wins with a few clients. With many clients, multicast wins again.
- A client far from the AP misses multicast frames, because they are never acknowledged or retried.
- Card 6 shows which fixes suit each traffic type, such as conversion to unicast, an mDNS gateway or Proxy ARP.
About this tool
Why can one video stream, or a room full of devices announcing themselves, slow down a whole Wi-Fi network? Multicast and broadcast frames go to every client at once, so the AP sends them at the slowest basic rate, only once, with no acknowledgement, and holds them until the next DTIM beacon if anyone is asleep. Choose a video stream, discovery chatter, ARP or push-to-talk audio, the band, the basic rate and the clients, and see how much of the channel it takes, when sending each client unicast frames is more efficient, which clients lose frames, what sleeping clients do to the timing, and what each fix saves and breaks: multicast-to-unicast conversion, DMS, an mDNS gateway, Proxy ARP or a higher basic rate.
What you'll learn
- Why multicast and broadcast use so much airtime at a low basic rate
- When converting multicast to unicast is more efficient, and when it isn't
- Why a client far from the AP loses multicast frames but not unicast ones
- How to handle video, push-to-talk, mDNS discovery and ARP on Wi-Fi
Common questions
Why is multicast slow on Wi-Fi?
A multicast frame has to reach every client, so the AP sends it at one of the basic rates, usually the lowest, such as 6 Mb/s or even 1 Mb/s. A 4 Mb/s video stream sent that way can take three quarters of the channel's airtime, while each client could receive it hundreds of times faster as unicast.
What is multicast-to-unicast conversion?
A feature that sends a multicast stream to each client that joined it as ordinary unicast frames, at that client's own rate and acknowledged. It needs IGMP snooping so the AP knows who joined. It saves airtime for a few receivers and delivers every packet, but its cost grows with each receiver, so APs usually fall back to multicast above a set number of clients.
How do you reduce mDNS and ARP traffic on Wi-Fi?
Not by converting it, since every client listens and would each need its own copy. An mDNS gateway answers discovery queries itself, and Proxy ARP, a service in IEEE 802.11, drops ARP requests for devices that aren't the AP's clients and passes the rest to just the client being asked.
Free for private and educational use. This interactive model is a simplified teaching aid and may contain mistakes. It is provided as is, without warranty. Use it to understand the concepts, not as a substitute for a site survey, vendor documentation or professional design advice.