IBM Books

Planning Volume 2, Control Workstation and Software Environment

|Question 1: Do you need a system for parallel computing with a switch?

| |

|Why do you need an SP system? For LAN consolidation? For data mining? For |engineering or scientific computing? See Figure 4 for some typical uses of an SP system.

|Figure 4. Typical uses of an SP system (not to scale)

View figure.

|Which applications do you want to run on this system? Each SP node is a |powerful SMP running the AIX 5L 5.1 or AIX 4.3.3 |operating system and some special SP support programs. Thousands of IBM |RS/6000 and e(logo)server pSeries applications can run unchanged on the SP |with a single point of control for system management. Do you need the |additional power of parallel computing? Do you need the high-performance |communication within your system that an SP switch can provide?

|Considering parallel computing


|Along with this question, you need to decide whether you want to reap the |benefits that parallel computing offers by running parallel |applications. Parallel computing involves breaking a serial application |into its logical parts and running those parts simultaneously. As a |result, you can solve large, complex problems quickly.

|Parallel applications can be broadly classified into two classes by |considering whether the parallelism can be achieved through the use of a |middleware software layer or whether the application developer |needs to explicitly parallelize the problem by working with the source code |and adding directives and code to achieve speedup.

|Examples of a parallelized software layer are a parallel relational |database such as DB2 Parallel Edition, or the Parallel Engineering and |Scientific Subroutine Library (Parallel ESSL), which lets you execute an SQL |statement, or call a matrix multiplication routine, and achieve problem |speedup without having to specify how to achieve the parallelism.

|An example of explicit parallelism is taking an existing serial FORTRAN |program and adding calls to a message passing library to distribute the |computations among the nodes of the SP system. In this case, various |parallel tools such as compilers, libraries, and debuggers are |required.

|Choosing a switch

|Consider whether you can benefit from using a switch to interconnect the |nodes on your SP system. |

|A switch provides low latency, high-bandwidth communication between nodes, |supplying a minimum of four paths between any pair of nodes. Switches |provide enhanced scalable high-performance communication for parallel job |execution and dramatically speed up TCP/IP, file transfers, remote procedure |calls, and relational database functions. Using a switch offers the |following improved capabilities: |


|Your choices for a switch supported with PSSP 3.4 are the SP Switch2 |and the SP Switch.Table 1 describes the PSSP 3.4 support of these |switches. | | | | | | | | | |

|Table 1. The switches supported by PSSP 3.4

Switch feature Description
SP Switch2

The SP Switch2 (feature code 4012) has sixteen ports for node connections and 16 ports for switch to switch connections.

The SP Switch2 can interconnect all the processor nodes that are currently available from IBM. Some older nodes that you might already have are also supported on this switch. See Question 8: Which and how many nodes do you need? for information about them.

When the control workstation and all the nodes are running PSSP 3.4, you have optional switch connectivity. In other words, you can connect a selection of nodes to the SP Switch2 and leave some nodes off the switch. For instance, the RS/6000 Enterprise Server S70 and S7A are not supported with the SP Switch2. If you have any, they can still be in your system running PSSP 3.4, but not connected to the SP Switch2.

The SP Switch2 supports two different switch configurations so that nodes can communicate over one or two switch planes. You can have improved communication performance with two switch planes operational, and higher availability since one switch plane can continue operating even when you take a switch down for maintenance.

A two-plane SP Switch2 system has two sets of switches and two switch adapters per node. The switch planes are disjoint - each is cabled exactly like a single plane, both with the same topology, and communication across the pair of planes is achieved by a data striping algorithm in the software. You can only use this option with nodes that can have two adapters - one for connecting to one switch plane and another for connecting to the other switch plane. You cannot install one adapter in some nodes and two adapters in others.

The SP Switch2 supports multiple node switch boards in one frame. With PSSP 3.4, you can have up to eight SP Switch2 node switch boards in a single SP frame. This is advantageous for installations that require a large number of switch connections for SP-attached servers or clustered enterprise server configurations. This is a frame configured only with SP Switch2 switches.

The SP Switch2 can be configured with one switch plane. In that case, it is like the SP Switch with one adapter per node attached to the one switch plane network. But it also has the added functional benefits, like relaxed node placement rules and optional connectivity.

The PSSP 3.2 or later software supports the removable and hot-pluggable interposer cards that provide the bulkhead connections to the switch cable, the concurrent replacement of any failed power supplies or fans, and replacement of the supervisor while the switch is operating.

The SP Switch2 does not support SP system partitioning or the SP Switch Router.

SP Switch (16-port) The SP Switch (feature code 4011) has 16 ports for node connections and 16 ports for switch to switch connections. It interconnects all the currently supported nodes and the SP Switch Router. All the nodes in the system must be connected to the SP Switch.
SP Switch (8-port) This is a lower-cost version of the SP Switch (feature code 4008) that offers 8 internal connections to provide enhanced functions for small systems with up to 8 total nodes. It can interconnect only thin and wide SP rack-mounted nodes, not high nodes. It does not support SP-attached servers or scaling to larger systems.
Switch incompatibility statement:

Switch types cannot be mixed in any SP system - not even in separate SP system partitions. If you want to use the SP Switch2 but you still have some nodes that are not supported on the SP Switch2, you can leave them off the switch as long as all the nodes run PSSP 3.4 . If you have nodes that are not supported on the SP Switch2 and you need to run mixed levels of PSSP, use the SP Switch.

The older High Performance Switch series is not supported. If you still have a High Performance Switch and you plan to add any of the nodes introduced since PSSP 2.4 or you plan to install or migrate your control workstation to PSSP 3.4, you must convert all your switches.

Hardware planning is described in Volume 1.

This book covers switch planning only in the context of system configuration. Adapters are used to connect a node to the switch subsystem. For physical planning regarding switch adapters, wiring, cabling, and allowing for future hardware expansion, see the book IBM RS/6000 SP: Planning Volume 1, Hardware and Physical Environment.

|For the SP Switch, there are frame, switch, and node placement and |numbering rules and there are switch port numbering rules to be understood and |honored for the supported switch capsule configurations. The SP Switch2 |has some system configuration rules, but node placement rules have been |relaxed. Nodes can be placed anywhere allowed by the physical |restrictions. The node switch port numbers are not predefined. |You can connect a node to any available switch port and the numbers are |generated when the switch is started. See Understanding placement and numbering.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]