Testing Multicast Speed Limits

TCP automatically adjusts its speed to the capability of the processes using it and enforces bandwidth sharing so that every process gets a turn. With multicast, you must determine and explicitly set those limits.

Without the proper configuration, multicast delivers its traffic as fast as possible, overrunning the ability of consumers to process the data and locking out other processes that are waiting for the bandwidth. You can tune your multicast and unicast behavior using mcast-flow-control in gemfire.properties.

Using Iperf

Iperf is an open-source TCP/UDP performance tool that you can use to find your site’s maximum rate for data distribution over multicast. Iperf can be downloaded from web sites such as the National Laboratory for Applied Network Research (NLANR).

Iperf measures maximum bandwidth, allowing you to tune parameters and UDP characteristics. Iperf reports statistics on bandwidth, delay jitter, and datagram loss. On Linux, you can redirect this output to a file; on Windows, use the -o filename parameter.

Run each test for ten minutes to make sure any potential problems have a chance to develop. Use the following command lines to start the sender and receivers.


iperf -c -u -T 1 -t 100 -i 1 -b 1000000000


-c address

Run in client mode and connect to a multicast address



-T #

Multicast time-to-live: number of subnets across which a multicast packet can travel before the routers drop the packet

Note: Do not set the -T parameter above 1 without consulting your network administrator. If this number is too high then the iperf traffic could interfere with production applications or continue out onto the internet.

-t Length of time to transmit, in seconds
-i Time between periodic bandwidth reports, in seconds
-b Sending bandwidth, in bits per second


iperf -s -u -B -i 1



Run in server mode



-B address

Bind to a multicast address
-i # Time between periodic bandwidth reports, in seconds

Note: If your GemFire distributed system runs across several subnets, start a receiver on each subnet.

In the receiver’s output, look at the Lost/Total Datagrams columns for the number and percentage of lost packets out of the total sent.

Output From Iperf Testing:

[	ID] Interval	 Transfer	 Bandwidth	 Jitter	 Lost/Total Datagrams
[	 3]	0.0- 1.0 sec	 129 KBytes	 1.0 Mbits/sec	0.778 ms	 61/	151 (40%)
[	 3]	1.0- 2.0 sec	 128 KBytes	 1.0 Mbits/sec	0.236 ms	 0/	 89 (0%)
[	 3]	2.0- 3.0 sec	 128 KBytes	 1.0 Mbits/sec	0.264 ms	 0/	 89 (0%)
[	 3]	3.0- 4.0 sec	 128 KBytes	 1.0 Mbits/sec	0.248 ms	 0/	 89 (0%)
[	 3]	0.0- 4.3 sec	 554 KBytes	 1.0 Mbits/sec	0.298 ms	 61/	447 (14%)
Rerun the test at different bandwidths until you find the maximum useful multicast rate. Start high, then gradually decrease the send rate until the test runs consistently with no packet loss. For example, you might need to run five tests in a row, changing the -b (bits per second) parameter each time until there is no loss:
  1. -b 1000000000 (loss)
  2. -b 900000000 (no loss)
  3. -b 950000000 (no loss)
  4. -b 980000000 (a bit of loss)
  5. -b 960000000 (no loss)

Enter iperf -h to see all of the command-line options. For more information, see the Iperf user manual.