This test detects nodes that are injecting corrupted packets into the switch network. The mult_senders_test command starts this test. For detailed information about this command, its flags, arguments, and usage examples, see PSSP: Command and Technical Reference. The -g flag can be used to run the test with the SPD GUI, but you must specify the command operands and flags on the command line.
The -n flag is used to specify the switch plane number. -n 0 specifies plane 0 and -n 1 specifies plane 1. Both planes cannot be specified on one invocation of this command.
Run this test if one or more of the nodes are reporting that they received "bad packets." This may indicate a situation where there is a malfunctioning switch adapter in the system that is generating bad packets. You want to detect such "bad sender" nodes. The multiple senders/single receiver test finds the malfunctioning switch adapter among all of the nodes in the system.
Select a receiver node to be used by the test. The receiver node is usually one of the nodes that are reporting bad packet events. Then decide which nodes can be used as senders. The receiver node and nodes that will be used as senders cannot run parallel applications during this test. By default, all nodes are allowed, so be careful to avoid disturbing applications that are running. The nodes that are not allowed will not be affected directly. However, since the test implies stress traffic in the switch network, the performance of applications running on all nodes may be affected.
Invoke the test specifying the desired receiver node. Also specify the nodes that are allowed to be used as senders, or alternatively the nodes that are forbidden (because they are running critical applications).
The test does not require user intervention. In the beginning, the test notifies the user which sender nodes are participating. The selected senders send data to the receiver, and the test progress is monitored until it completes.
The test monitors error reports from all switch network components during the iterations. If a critical fault occurs, the test displays a message about it and terminates. In this case, contact IBM hardware support to replace the faulty component. Otherwise, the test continues until all iterations are done. The test then either displays a message that contains the list of bad senders, or notifies you that no errors were found.