The source and a variety of binaries of the tools are available free of charge on the Informatica Marketplace. After expanding the files, the appropriate binary then can be invoked from a command shell with the "-h" option to get a help screen. The binary directory also contains a script that was used to build the binaries.
msend -h
Usage: msend [-1|2|3|4|5] [-b burst_count] [-d] [-h] [-l loops] [-m msg_len] [-n num_bursts] [-p pause] [-P payload] [-q] [-s stat_pause] [-S Sndbuf_size] group port [ttl] [interface] Where: -1 : pre-load opts for basic connectivity (1 short msg per sec for 10 min) -2 : pre-load opts for long msg len (1 5k msg each sec for 5 seconds) -3 : pre-load opts for moderate load (bursts of 100 8K msgs for 5 seconds) -4 : pre-load opts for heavy load (1 burst of 5000 short msgs) -5 : pre-load opts for VERY heavy load (1 burst of 50,000 800-byte msgs) -b burst_count : number of messages per burst [1] -d : decimal numbers in messages [hex]) -h : help -l loops : number of times to loop test [1] -m msg_len : length of each message (0=use length of sequence number) [0] -n num_bursts : number of bursts to send (0=infinite) [0] -p pause : pause (milliseconds) between bursts [1000] -P payload : hex digits for message content (implicit -m) -q : loop more quietly (can use '-qq' for complete silence) -s stat_pause : pause (milliseconds) before sending stat msg (0=no stat) [0] -S Sndbuf_size : size (bytes) of UDP send buffer (SO_SNDBUF) [65536] (use 0 for system default buff size) -t : tcp ('group' becomes destination IP) [multicast] -u : unicast udp ('group' becomes destination IP) [multicast] group : multicast group or IP address to send to (required) port : destination port (required) ttl : time-to-live (limits transition through routers) [2] interface : optional IP addr of local interface (for multi-homed hosts)mdump -h
Usage: mdump [-h] [-q] [-Q Quiet_lvl] [-r rcvbuf_size] [-p pause_ms/num] [-v] [-s] group port [interface] Where: -h : help -o ofile : print results to file (in addition to stdout) -p pause_ms[/num] : milliseconds to pause after each receive [0: no pause] and number of loops to apply the pause [0: all loops] -Q Quiet_lvl : set quiet level [0] : 0 - print full datagram contents 1 - print datagram summaries 2 - no print per datagram (same as '-q') -q : no print per datagram (same as '-Q 2') -r rcvbuf_size : size (bytes) of UDP receive buffer (SO_RCVBUF) [4194304] (use 0 for system default buff size) -s : stop execution when status msg received -t : Use TCP (use '0.0.0.0' for group) -v : verify the sequence numbers group : multicast address to receive (required, use '0.0.0.0' for unicast) port : destination port (required) interface : optional IP addr of local interface (for multi-homed hosts) [INADDR_ANY]mpong -h
Usage: ./mtools/FreeBSD-6-i386/mpong [-h] [-i] [-o ofile] [-r rcvbuf_size] [-S Sndbuf_size] [-s samples] [-v] group port [ttl] [interface] Where: -h : help -i : initiator (sends first packet) [reflector] -o ofile : print results to file (in addition to stdout) -r rcvbuf_size : size (bytes) of UDP receive buffer (SO_RCVBUF) [4194304] (use 0 for system default buff size) -S Sndbuf_size : size (bytes) of UDP send buffer (SO_SNDBUF) [65536] (use 0 for system default buff size) -s samples : number of cycles to measure [65536] -v : verbose (print each RTT sample) group : multicast address to send on (use '0.0.0.0' for unicast) port : destination port interface : optional IP addr of local interface (for multi-homed hosts) [INADDR_ANY] Note: initiator sends on supplied port + 1, reflector replies on supplied port
The tools, msend in particular, have many options which are
useful in diagnosing a variety of multicast problems. To make the initial evaluation of
the network easy, the msend command has 5 numbered command-line
options (-1
through -5
)
which pre-load other options to values which test for the most common network
problems.
Both the msend and mdump commands take zero or more Unix-style options, followed by two required positional parameters: multicast address (group), and destination port. In the examples listed in this document, addresses and ports are used by default by Informatica's UMS product (formerly called "LBM"), but any addresses and ports can be used. However, for each step in the initial 5-step test, it is important to use different multicast addresses for each step. In fact, if you desire to run a particular test a second time, it is a good idea to chose a multicast address that is different from the previous run of the same test. (This is because the tests are verifying different ways that a multicast stream is initiated, so re-running a test on a multicast address that the switch and router is already initialized for will prevent the test from verifying the stream initiation condition.)
The msend command has an optional third positional parameter which is the TTL (Time To Live) for the sent packets. This field controls how widely the multicast datagrams can be distributed in an interconnected group of networks. A TTL of 1 prevents the datagram from crossing any routers, restricting the datagrams to a single network segment (LAN). However, many switches and routers actually operate less efficiently with a TTL of 1, so the tool defaults to a TTL of 2. It is assumed that you want to verify the performance of your routers, so the examples below use a TTL of 2. For some organizations, multiple routers may need to be crossed, which would require the TTL to be increased.
The msend command has an optional forth positional parameter which is the IP address of the desired network interface. The mdump command also can specify a network interface as its third positional parameter. This parameter is only needed on a multi-homed host (machine with more than one network interface). With normal unicast destination addresses, IP uses routing tables to determine the correct interface to send packets. With multicast, there is no "correct" interface - the application should specify which interface to use. (It is possible for an application to let the operating system choose an interface, but this can lead to systems that work properly for a time, and then mysteriously stop working due to minor hardware or operating system upgrades. It is a much better idea to specify the correct interface for your network architecture.) In the examples below, it is assumed that the sending and receiving hosts are single-homed, and therefore do not require the interface.
The mdump command attempts to set its socket to have a 4 MB UDP receive buffer. Many operating systems will not grant a request that large (the tool will inform you how large a buffer it was able to get). However, if your sending machine is a reasonably high-power machine, the receiver may very well need a large receive buffer. You can use the "netstat" command (usually with the "-s" option) to see UDP statistics, including packets dropped due to the receive buffer overflowing. If you consistently get loss with tests 3 - 5, it may be necessary to have your system administrator increase the maximum allowable receive buffer (it's a kernel tuning parameter). See our THPM document for advice in this area.
The msend command attempts to set its socket to have a 64 KB UDP send buffer. Many operating systems will not grant a request that large (the tool will inform you how large a buffer it was able to get). However, we have found that especially when sending fairly large datagrams, less than 64 KB of send buffer prevents the sending machine from reaching its maximum send rate. In fact, if your sending datagrams are themselves approaching 64 KB in size, you may need an even larger send buffer, perhaps three times the maximum datagram size. However, due to a possible bug in Linux, you should not set your send socket buffer more than 192 KB (196608).
Finally, it is very possible to experience loss due to a sufficiently-large capability mismatch between the sending and receiving machines. It might be because the sending machine has a faster network interface than the receiving machine, or a faster CPU, or an operating system that is more efficient at processing UDP. For the purposes of evaluating your network, it is suggested that the sending and receiving machines be as closely-matched as possible.
Copyright 2005 - 2011 Informatica, Inc.