Most speed tests on the Internet are actually multi-user capacity tests. They pack the connection with as much data as it can take and report the peak number. That gives you a nice big result, but it completely disregards performance. Packets are being lost, reordered, and delayed, and the test doesn't care.
Real applications do care. VoIP, video conferencing, and cloud services all depend on UDP traffic that is extremely sensitive to packet loss. The question isn't how much data you can force through the pipe. It's how much you can send before quality breaks down.
MCS doesn't flood the connection and hope for the best. It uses a methodical ramp-up process that finds the maximum sustainable capacity while respecting packet loss thresholds.
MCS sends UDP packets between two test points, gradually increasing the data rate with each cycle. The load grows in controlled steps, not an uncontrolled flood.
At each cycle, MCS monitors packet loss. If loss exceeds the acceptable threshold (defined in the test specification), it backs off, then ramps up again. This ensures the result reflects what the connection can sustain without degradation.
The final result is the highest throughput achieved within the acceptable packet loss level. This is the real capacity your applications can use, not a peak burst that ignores quality.
MCS doesn't just report a single capacity figure. It gives you the full picture of how your connection behaves under increasing load.
The highest throughput achieved within acceptable packet loss thresholds. Downstream and upstream tested independently.
See exactly where loss begins as load increases. Know the tipping point where your connection starts to degrade.
Test with the exact UDP packet size your application uses. G.711 VoIP uses 172 bytes, video codecs use different sizes. Results depend on getting this right.
Define what level of packet loss is acceptable for your use case. MCS finds the maximum capacity that stays within your tolerance.
Capacity is tested bidirectionally. Asymmetric connections (common with cable and DSL) often have very different upstream and downstream limits.
Based on the measured capacity and codec packet size, MCS calculates how many simultaneous VoIP calls or media streams the connection can support.
A speed test and a capacity test may both report throughput, but the methodology determines whether the result is useful.
| Typical Speed Test | MCS Capacity Test | |
|---|---|---|
| Protocol | TCP (HTTP download) | UDP (matches real media traffic) |
| Method | Flood the connection, report the peak | Controlled ramp-up with loss monitoring |
| Packet loss | Ignored entirely | Measured at every stage, test adapts to it |
| Packet size | Not configurable | Configurable to match your codec or application |
| Result meaning | Peak burst (momentary maximum) | Sustainable capacity within loss tolerance |
| Bidirectional | Sequential up/down | Independent upstream and downstream |
| VoIP/media relevance | Low, TCP behavior differs from UDP | High, tests with actual media packet characteristics |
| Call count estimate | No | Yes, based on measured capacity and codec size |
Determine how many concurrent calls a customer's connection can support before quality degrades. Pre-qualify sites before deployment.
Validate that WAN links and branch connections can handle the combined load of voice, video, and data without one degrading the others.
Prove to customers exactly how much usable capacity their connection delivers. Resolve disputes with data, not opinions.
Home connections often have severe upstream limitations. Capacity testing reveals whether a remote worker's connection can support the traffic their role demands.