CA2146169C - Method and system for dynamically selecting a communications mode - Google Patents
Method and system for dynamically selecting a communications modeInfo
- Publication number
- CA2146169C CA2146169C CA002146169A CA2146169A CA2146169C CA 2146169 C CA2146169 C CA 2146169C CA 002146169 A CA002146169 A CA 002146169A CA 2146169 A CA2146169 A CA 2146169A CA 2146169 C CA2146169 C CA 2146169C
- Authority
- CA
- Canada
- Prior art keywords
- computer system
- obtaining
- particular operation
- communication mode
- predefined
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
Abstract
In a multi-processor parallel processing computer environment different communication modes are available for performing an information distribution operation (e.g., a broadcast) between processors. The technique comprises automatically selecting an optimal communications mode at operation run-time. The selection decision utilizes hardware parameters of the system (e.g., communication speed between processors) and run-time parameters (e.g., number of nodes to broadcast a message to). The communication mode selection decision seeks to optimize factors such as time required to execute or work space requirements of the distribution operation.
Description
21~6169 METHOD AND SYSTEM FOR DYNAMICALLY SELECTING A COMMUNICATION MODE
Technical Field This invention relates in general to the selection of software resources within an information processing system, and more particularly, to the dynamic selection of a communication mode (for performing a particular operation) from a number of available communication modes for that operation.
Background Art In the information processing environment, systems are programmed using many techniques. Techniques are chosen for specific tasks based upon their characteristics. Usually, no one technique performs best in all situations. In the past there has been no way to dynamically choose the best technique while a program is running, so a compromise technique has always been used. Thus, a sacrifice in system performance often results depending upon the program being executed.
One particular situation where this problem arises is in multiple processor systems, and in particular, in a parallel processing system.
In such a system, each processor has means to communicate with the other processors and various protocols and modes exist to perform a communication. Since the range of tasks that a parallel processing system may handle varies greatly, the messaging structure could be optimized for various different situations. Unfortunately, when the operating software for a parallel processing system is designed, it is difficult to know the exact applications that will run on the system.
Therefore, it is difficult to predict what type of communication mode between nodes of the processing system would be optimal.
For example, one use of inter-processor communications is in the "broadcasting" of messages from one node to many other nodes of the multinode computer system. Depending upon such factors as the length of the message, speed of the communication means between nodes, number of nodes for the message to be sent to, and the mode used to distribute the message, the time interval required to distribute the message among 21~616~
_ nodes may vary greatly.
One implementation of a parallel processing system is the IBM SP1 (Scalable Power Parallel Systems 9076-SPl). In this system, there exist three primitives for communication between nodes. These primitives include send, receive, and send/receive. A Collective Communications Library (CCL) manages complex inter-processing node communications. The CCL is called by an application program, and the CCL thereafter calls the appropriate primitive(s) to effectuate inter-processing node communications. In the SPl implementation, only a single mode is used to distribute messages, i.e., an all-to-all communication mode. This mode was chosen for its overall good performance under varied conditions. There are many circumstances however, where other modes would have been a better choice. For example, a hypercube communication mode is faster than the all-to-all mode when messages to be broadcast are short.
Varying modes of communication can be optimal for differing combinations of parameters, such as the number of nodes, the time required to transmit a message, and the overall message length. Thus, the problem that exists with a computer system wherein the mode of communication is fixed, is that the mode is typically not optimal for each application program to run on the computer system.
Thus, a further problem not addressed by the prior art is how to automatically select an optimal communication mode for the type of application program currently being run. It would be advantageous if means were provided for dynamically determining various parameters that may influence the performance of a communication mode. Also, additional means could be provided for the application to specify the performance characteristic to be optimized, such as distribution time, execution speed, or the effect on computer system traffic (which includes traf~ic on the network fabric connecting the processors). Further, it would be advantageous if the parameters governing communication mode selection were updated and optimized as the system ran and not merely fixed at the start of an application program.
Also, it would be beneficial if the communication mode selection 21~6169 process was transparent to the application program. More specifically, if the application program issued a command to broadcast a message to all nodes, the application program should only have to issue a single command. This command would cause all mode selection decisions to be made by the computer system. With such a system, the application programmer would not have to be concerned with communication mode selection because the selection is dynamically performed by the system.
The application code would be easier to read because only a single command is needed to dynamically select and execute an operation.
Additionally, message handling would be more efficient because the library programmer has a better overall knowledge of the system than the application programmer. The invention described herein addresses all of the above-described objects and contains all of the described advantages.
Summary of the Invention Briefly described, in accordance with a first aspect of the invention, a method is provided for dynamically selecting one of a plurality of communication modes for performing a particular operation.
The method includes obtaining a run-time parameter associated with the particular operation; and selecting one communication mode from the plurality of communication modes using the associated run-time parameter. More specifically, the selecting step can include employing a predefined decision function to select the one communication mode, and obtaining a hardware parameter of the computer system for use in selecting the one communication mode. Further, the one communication mode is preferably selected using the associated run-time parameter so as to optimize a performance characteristic of the computer system.
In another aspect, the invention comprises a method for performing a particular operation employing a selected communication mode within a multinode computer system. This method includes selecting a mode of communication from a plurality of modes of communication for performing the particular operation so as to optimize a performance characteristic of the multinode computer system; and performing the particular 2146iG9 operation within the multinode computer system using the selected mode of communication.
In still another aspect, the invention comprises a multinode computer system for performing a particular operation. The system includes processing means for obtaining a run-time parameter associated with the particular operation and for selecting one communication mode from a plurality of communication modes using the associated run-time parameter.
Brief Description of the Drawings The above-described objects, advantages and features of the present invention, as well as others, will be more readily understood from the following detailed description of certain preferred embodiments of the invention, when considered in conjunction with the accompanying drawings in which:
FIG. 1 is a simplified block diagram of a multinode computer system;
FIG. 2 is a simplified flowchart of one embodiment of a process for selecting a communication mode in accordance with the present invention;
FIG. 3 is a flowchart of one embodiment of a hardware characterization process for the selection process of FIG. 2; and FIG. 4 is a flowchart of one embodiment of a decision making process for the selection process of FIG. 2.
Best Mode for Carrying Out The Invention FIG. 1 illustrates a typical loosely coupled parallel processing system, generally denoted 10. The parallel processing system comprises a plurality of processors 101, a plurality of network connections 102, and a network fabric 103. Processors lOl are attached to network fabric 103 by network connections 102. Each processor 101 is capable of communicating with each other processor 101 through the network fabric 103. Processor 101 is sometimes referred to herein as a node.
As recited herein, the term "multinode" computer system refers to a computer system comprised of a plurality of processors, such as the 21~61~9 above-referenced IBM SPl parallel processing system. Also, as used herein, the term "communication mode" refers to the method by which transfer of information is performed between the nodes. Examples include an "all-to-all" and a "hypercube" communication mode.
An application program will request the computer system to perform a plurality of "operations". Each particular operation requires communication among the nodes of the parallel processing system. Thus, each operation requires the use of a communication mode. An example of such an operation would be a "broadcast". The broadcast operation requires the distribution of a "message" to a plurality of nodes.
Another example of an operation would be a "scatter". The scatter operation distributes a message only to a certain "number of nodes" in the system. Other examples are presented in Table 1.
214616~
Table 1 Collective Communications Subroutines FORTRAN CDESCRIPTION
MP_BCAST mpc_bcast Sends a message from one task to all tasks in the group.
MP_REDUCE mpc_reduce Applies a reduction operation on all the tasksin the group and places the result in one task.
The reduction operations include addition, multiplication, maximum, minimum, bitwise-AND, bitwise-OR, bitwise-XOR, Boolean-AND and Boolean-OR and operations you define yourself.
MP_COMBINE mpc_combine Applies a reduction operation and places the result in all tasks in the group. This is operationally equivalent to a reduce followed by bcast.
MP_SCATTER mpc_scatter Distributes distinct messages from a single source task to each task in the group. This type of operation is also known as one-to-all personalized communication or distribute.
MP_GATHER mpc_gather Gathers distinct messages from each task in the group to a single destination task. It is also called collect and is the reverse operation of scatter.
MP_SYNC mpc_sync Creates a barrier synchronization in the group.
Each task when reaching the syne call, blocks until all tasks in the group reach the corresponding syne call.
MP_SHIFT mpc_shift Shifts data, with or without wraparound, up or down some number of steps in the group.
MP_PREFIX mpc_prefix Applies parallel prefix with respect to a reduction operation across a task group and places the corresponding result in each task in the group. This operation is also called scan.
MP_CONCAT mpc_concat Concatenation (to all tasks) in the group. It is logically equivalent to each task in the group performing a one-to-all broadcast. It is also referred to as completed broadcast or expand.
MP_INDEX mpc_index Each task in a group performs a seatter operation sending a distinct message to all the tasks in the group in order by rank. It is also called multi-scatter, all-to-all personalized communication, or complete exchange.
21~6169 A "decision function" is used to select the communication mode for performing a particular distribution operation. The decision function uses one or more "parameters" to select the communication mode. One type of parameter is a "run-time" parameter which is associated with the particular operation. An example of a run-time parameter associated with a broadcast operation would be the message to be broadcast.
Another type of parameter is a "hardware parameter". An example of a hardware parameter would be "execution speed" of the processor.
Another example would be the "memory move" speed of the processor. This is the speed at which the processor can move values from one location in its memory to another. Memory move speed is a useful metric because certain communication modes require the manipulation of large amounts of data in the processor's memory. In one simple embodiment, the hardware parameters could be obtained at the beginning of the job.
Both types of parameters are used by the decision function in conjunction with certain "predefined relationships", which are incorporated in the computer system's library when developed. Run-time and hardware parameters are employed in defining the relationships.
Each particular operation using each communication mode is described by one of the relationships. Examples of "relationships" include the "time interval required for executing," "computer system traffic generated by," and "work space required for performing" the particular operation using each communication mode.
The relationships are "prioritized" by a library developer to represent some preference in selecting a communication mode. This preference may be to minimize (i.e., optimize) time or work space required for the execution of the operation. The operation is typically executed within a "job" on a computer system. The job may, however, include multiple operations that require the dynamic selection process.
FIG. 2 is a flowchart illustrating one embodiment of the overall process for selecting a technique for a particular task. Initially, a job is started, 200, "JOB STARTS," that requires the use of an operation that may be performed by a plurality of communication modes. A hardware characterization test is then run, 201, "HARDWARE CHARACTERIZATION."
21~616~
This test provides a plurality of hardware parameters that will be used within the decision function that determines which communication mode will be selected. Next, a set of run-time parameters are obtained that will be used in the decision function, 202, "OBTAIN RUN-TIME
PARAMETERS." These parameters may include, for example, a message to be broadcast to a plurality of nodes, or a quantity of nodes for a message to be broadcast to. The decision function, 203, "DECIDE WHICH
MODE," uses the run-time and hardware parameters to decide which communication mode to select. The selected communication mode is then employed, 204, "EXECUTE APPROPRIATE MODE." In another embodiment, the job may include a plurality of identical or different type operations, each requiring the dynamic selection of a communication mode.
As noted briefly above, the dynamic communication mode selection process in accordance with the present invention is based upon many parameters. These parameters are derived from a plurality of sources.
A first source of parameters are hardware parameters of the multinode computer system. For example, in one embodiment, a hardware characterization test is preferably run at the beginning of a job to obtain hardware performance characteristics such as processor execution speed, memory move speed, and network interconnect speed. A flowchart of one embodiment of a hardware characterization process is presented in FIG. 3. This process includes a plurality of tests used to characterize the hardware and obtain hardware parameters.
First, an execution speed test is run, 301, "EXECUTION SPEED TEST."
In this test, the processor executes a series of instructions while the elapsed time is recorded. Next, an array of values is copied within the processor's memory, 302, "MEMORY MOVE SPEED TEST." The elapsed time is again recorded. The time it takes a series of messages to pass between nodes is recorded in a network speed test, 303, "NETWORK SPEED TEST."
The results of the aforementioned tests are returned, 304, "RETURN
PERFORMANCE VALUES," for inclusion in the decision function. In another embodiment of this invention, other tests used to characterize the hardware may be added such as a floating point math performance test.
The method for carrying out these and other hardware characterization 21g61fi9 tests would be obvious to one of ordinary skill in the art.
In a further embodiment, the hardware characterization test may be run on a periodic basis during execution of the job so that the hardware parameters used by the decision function are always representative of the current system. For example, if a job starts at a time when the network is lightly loaded, the hardware parameter associated with computer system traffic would indicate a low traffic level and thus, a fast network connection between processors. At sometime later, however, the computer system traffic may increase resulting in the network becoming congested and, thus, a slower network connectivity. Updating the computer system traffic parameter would allow the selection decision to be more accurate in this instance. Updating may occur every time a decision is to be made, every ten times a decision is to be made, or on any other periodic or non-periodic basis. It is important to note that it would be imprudent to run the hardware characterization test very often because the time taken by the test may use an excessive amount of computer time, thereby degrading overall system performance.
In a further embodiment, the hardware parameter updating may be done dynamically with distribution of each message. For example, a short, 2 or 3 byte, time stamp could be placed at the end of each message greater than a certain length. The length of the message would be chosen so that the additional bytes used by the time stamp do not significantly increase the overall length of the message. In one embodiment, a time stamp may be added to each message greater than 1000 bytes in length. Use of a time stamp enab]es calculation of the time interval required for the associated message to traverse the network.
The calculated time interval may then be used to determine the speed of the network, and to update the computer system traffic parameter.
The second source of parameters used in the decision function is information provided by the application program, for example, contained in a request for a particular operation received from the application program running on a processing node. In the case of a scatter operation, examples include the length of the message (to be distributed), and the number of processing nodes to which the message is _ ` 214616g to be distributed. Relevant parameters for operations currently known, or those yet to be written, would be obvious to one of ordinary skill in the art.
Various characteristics of each communication mode for each operation are described by a predefined relationship or formula. The predefined relationship is defined by the aforementioned run-time and hardware parameters and represents quantities such as the time interval an operation requires to execute, the work space requirements of an operation, and the computer system traffic caused by the operation.
Two examples of communication modes for a broadcast operation are the all-to-all mode and the hypercube mode. The time intervals required by a broadcast operation implemented using the all-to-all and hypercube modes may be easily computed, in addition to other characteristics of these two communication modes. Formulas for calculating time, computer system traffic, and work space requirements are set forth below for both the all-to-all and hypercube modes.
The variables common to the formulas are:
N = Number of nodes;
L = Latency - time required to initiate a transmission;
x = Time required to transmit one byte of data;
m = Message length;
T = Time required to complete the mode;
W = Work space requirements; and S = Computer system traffic.
The time required to complete a communication mode can be expressed:
For hypercube mode broadcast as:
T =llog2Nl( L + mx) 214616g For all-to-all mode broadcast as:
'T= 3 (N-l) (L + NX) The computation of work space requirements for a communication mode can be expressed:
For hypercube mode broadcast as:
W = O
For all-to-all mode broadcast as:
W = O
(Note: Neither of these modes re~uire any work space, others may.) The computation of computer system traffic for a communication mode can be expressed:
For hypercube mode broadcast as:
m (N-l ) For all-to-all mode broadcast as:
mloy2N-~m(N~
The computation of these parameters (and others) for additional broadcast modes will be straightforward for one skilled in the art.
By way of example, a flowchart of one embodiment of a decision function for selecting which communication mode will be used for a broadcast operation is presented in FIG 4. First, a decision is made as 21461~9 to whether the length (m) of the message to be broadcast is very small, 400, "IS m VERY SMALL?" If "yes," then a mode that is known to work well for a broadcast operation of very small messages is chosen, 401, "EXECUTE DEFAULT MODE FOR SMALL MESSAGES." If desired, the preliminary steps 400 and 401 could be excluded from the decision function.
Assuming that the message is not very small, the work space requirements for each communication mode are established, 402 "COMPUTE
WORK SPACE REQUIREMENTS." In this example there are two possible modes, mode 1 and mode 2. A decision is initially made, 403, "MODE 1 FITS?", whether mode 1 will fit into memory. If it will not, then inquiry is made whether mode 2 will fit in memory, 404, "MODE 2 FITS?". If neither mode will fit, then the process is stopped, 405, "STOP." Alternatively, if mode 2 fits in memory, then it is executed, 406, "EXECUTE MODE 2."
Again, this assumes that mode 1 did not fit in memory. If mode 1 did fit in memory then inquiry is made whether mode 2 also fits in memory, 407, "MODE 2 FITS?". If mode 2 does not fit in memory, then mode 1 is executed, 408, "EXECUTE MODE 1." This is because mode 1 is the only viable choice.
If both mode 1 and mode 2 fit into memory, then the time requirements for each mode are computed, 409, "COMPUTE TIME
REQUIREMENTS." Inquiry is made regarding whether there is a significant difference, between the times required for executing the two modes, 410, "IS DIFFERENCE SIGNIFICANT?" A significant difference in time might be a difference greater than five (5) percent. If the difference is significant, then a decision is made whether the time taken by mode 1 (Tl) is less than the time taken by mode 2 (T2), 411, "Tl < T2?". If time Tl is not less than time T2, then mode 2 is executed, 412, "EXECUTE
MODE 2." However, if time Tl is less than time T2, then mode 1 is executed, 413, "EXECUTE MODE 1." Essentially, the object here is to minimize the time needed to perform the broadcast.
If there is no significant difference between the time each mode requires, then a comparison based upon the next most important factor, e.g., computer system traffic, is made. First, the computer system traffic for the two modes is calculated, 414, "COMPUTE NETWORK TRAFFIC."
21~16~
Then, inquiry is made as to whether the network traffic of mode 1 (Sl) is less than the network traffic of mode 2 (S2), 415, "S1 < S2?". If the computer system traffic generated by mode 1 is less, then mode 1 is chosen, 416, "EXECUTE MODE 1," thus minimizing computer system traffic.
Alternatively, if the network traffic caused by mode 1 is greater than that of mode 2, then mode 2 is executed, 417, "EXECUTE MODE 2," again minimizing computer system traffic.
Note from the above discussion, that a preliminary step preferably precedes the full decision function. In this preliminary step (steps 400 and 401), a 'quick' in~uiry is made into whether the complete decision function needs to be executed. If the complete decision function is not needed, then a particular communication mode is automatically chosen, and the decision process is bypassed. For example, if a very short message is to be broadcast, then the time spent in the decision function may be longer than the time it takes to broadcast the message. Performing the complete decision function in such a case would be wasteful. Therefore, default communication mode with good short message performance is automatically chosen.
As a specific hardware embodiment of the invention, the multiple processors could comprise IBM RS/6000 processors, and the network fabric linking the processors could consist of a crossbar switch. In another embodiment, the network fabric might be a local area network, and the processors could comprise IBM PS/2 processors. One skilled in the art will recognize that processor types and network fabric types may vary greatly, and may even be mixed within the same system without departing from the scope of the present invention.
While the invention has been particularly shown and described with reference to a preferred selection method and apparatus embodiment therein, it will be understood by those skilled in the art that various other changes in form and detail may be made without departing from the spirit and scope of the invention. The claims appended hereto are intended to encompass all such modifications.
Technical Field This invention relates in general to the selection of software resources within an information processing system, and more particularly, to the dynamic selection of a communication mode (for performing a particular operation) from a number of available communication modes for that operation.
Background Art In the information processing environment, systems are programmed using many techniques. Techniques are chosen for specific tasks based upon their characteristics. Usually, no one technique performs best in all situations. In the past there has been no way to dynamically choose the best technique while a program is running, so a compromise technique has always been used. Thus, a sacrifice in system performance often results depending upon the program being executed.
One particular situation where this problem arises is in multiple processor systems, and in particular, in a parallel processing system.
In such a system, each processor has means to communicate with the other processors and various protocols and modes exist to perform a communication. Since the range of tasks that a parallel processing system may handle varies greatly, the messaging structure could be optimized for various different situations. Unfortunately, when the operating software for a parallel processing system is designed, it is difficult to know the exact applications that will run on the system.
Therefore, it is difficult to predict what type of communication mode between nodes of the processing system would be optimal.
For example, one use of inter-processor communications is in the "broadcasting" of messages from one node to many other nodes of the multinode computer system. Depending upon such factors as the length of the message, speed of the communication means between nodes, number of nodes for the message to be sent to, and the mode used to distribute the message, the time interval required to distribute the message among 21~616~
_ nodes may vary greatly.
One implementation of a parallel processing system is the IBM SP1 (Scalable Power Parallel Systems 9076-SPl). In this system, there exist three primitives for communication between nodes. These primitives include send, receive, and send/receive. A Collective Communications Library (CCL) manages complex inter-processing node communications. The CCL is called by an application program, and the CCL thereafter calls the appropriate primitive(s) to effectuate inter-processing node communications. In the SPl implementation, only a single mode is used to distribute messages, i.e., an all-to-all communication mode. This mode was chosen for its overall good performance under varied conditions. There are many circumstances however, where other modes would have been a better choice. For example, a hypercube communication mode is faster than the all-to-all mode when messages to be broadcast are short.
Varying modes of communication can be optimal for differing combinations of parameters, such as the number of nodes, the time required to transmit a message, and the overall message length. Thus, the problem that exists with a computer system wherein the mode of communication is fixed, is that the mode is typically not optimal for each application program to run on the computer system.
Thus, a further problem not addressed by the prior art is how to automatically select an optimal communication mode for the type of application program currently being run. It would be advantageous if means were provided for dynamically determining various parameters that may influence the performance of a communication mode. Also, additional means could be provided for the application to specify the performance characteristic to be optimized, such as distribution time, execution speed, or the effect on computer system traffic (which includes traf~ic on the network fabric connecting the processors). Further, it would be advantageous if the parameters governing communication mode selection were updated and optimized as the system ran and not merely fixed at the start of an application program.
Also, it would be beneficial if the communication mode selection 21~6169 process was transparent to the application program. More specifically, if the application program issued a command to broadcast a message to all nodes, the application program should only have to issue a single command. This command would cause all mode selection decisions to be made by the computer system. With such a system, the application programmer would not have to be concerned with communication mode selection because the selection is dynamically performed by the system.
The application code would be easier to read because only a single command is needed to dynamically select and execute an operation.
Additionally, message handling would be more efficient because the library programmer has a better overall knowledge of the system than the application programmer. The invention described herein addresses all of the above-described objects and contains all of the described advantages.
Summary of the Invention Briefly described, in accordance with a first aspect of the invention, a method is provided for dynamically selecting one of a plurality of communication modes for performing a particular operation.
The method includes obtaining a run-time parameter associated with the particular operation; and selecting one communication mode from the plurality of communication modes using the associated run-time parameter. More specifically, the selecting step can include employing a predefined decision function to select the one communication mode, and obtaining a hardware parameter of the computer system for use in selecting the one communication mode. Further, the one communication mode is preferably selected using the associated run-time parameter so as to optimize a performance characteristic of the computer system.
In another aspect, the invention comprises a method for performing a particular operation employing a selected communication mode within a multinode computer system. This method includes selecting a mode of communication from a plurality of modes of communication for performing the particular operation so as to optimize a performance characteristic of the multinode computer system; and performing the particular 2146iG9 operation within the multinode computer system using the selected mode of communication.
In still another aspect, the invention comprises a multinode computer system for performing a particular operation. The system includes processing means for obtaining a run-time parameter associated with the particular operation and for selecting one communication mode from a plurality of communication modes using the associated run-time parameter.
Brief Description of the Drawings The above-described objects, advantages and features of the present invention, as well as others, will be more readily understood from the following detailed description of certain preferred embodiments of the invention, when considered in conjunction with the accompanying drawings in which:
FIG. 1 is a simplified block diagram of a multinode computer system;
FIG. 2 is a simplified flowchart of one embodiment of a process for selecting a communication mode in accordance with the present invention;
FIG. 3 is a flowchart of one embodiment of a hardware characterization process for the selection process of FIG. 2; and FIG. 4 is a flowchart of one embodiment of a decision making process for the selection process of FIG. 2.
Best Mode for Carrying Out The Invention FIG. 1 illustrates a typical loosely coupled parallel processing system, generally denoted 10. The parallel processing system comprises a plurality of processors 101, a plurality of network connections 102, and a network fabric 103. Processors lOl are attached to network fabric 103 by network connections 102. Each processor 101 is capable of communicating with each other processor 101 through the network fabric 103. Processor 101 is sometimes referred to herein as a node.
As recited herein, the term "multinode" computer system refers to a computer system comprised of a plurality of processors, such as the 21~61~9 above-referenced IBM SPl parallel processing system. Also, as used herein, the term "communication mode" refers to the method by which transfer of information is performed between the nodes. Examples include an "all-to-all" and a "hypercube" communication mode.
An application program will request the computer system to perform a plurality of "operations". Each particular operation requires communication among the nodes of the parallel processing system. Thus, each operation requires the use of a communication mode. An example of such an operation would be a "broadcast". The broadcast operation requires the distribution of a "message" to a plurality of nodes.
Another example of an operation would be a "scatter". The scatter operation distributes a message only to a certain "number of nodes" in the system. Other examples are presented in Table 1.
214616~
Table 1 Collective Communications Subroutines FORTRAN CDESCRIPTION
MP_BCAST mpc_bcast Sends a message from one task to all tasks in the group.
MP_REDUCE mpc_reduce Applies a reduction operation on all the tasksin the group and places the result in one task.
The reduction operations include addition, multiplication, maximum, minimum, bitwise-AND, bitwise-OR, bitwise-XOR, Boolean-AND and Boolean-OR and operations you define yourself.
MP_COMBINE mpc_combine Applies a reduction operation and places the result in all tasks in the group. This is operationally equivalent to a reduce followed by bcast.
MP_SCATTER mpc_scatter Distributes distinct messages from a single source task to each task in the group. This type of operation is also known as one-to-all personalized communication or distribute.
MP_GATHER mpc_gather Gathers distinct messages from each task in the group to a single destination task. It is also called collect and is the reverse operation of scatter.
MP_SYNC mpc_sync Creates a barrier synchronization in the group.
Each task when reaching the syne call, blocks until all tasks in the group reach the corresponding syne call.
MP_SHIFT mpc_shift Shifts data, with or without wraparound, up or down some number of steps in the group.
MP_PREFIX mpc_prefix Applies parallel prefix with respect to a reduction operation across a task group and places the corresponding result in each task in the group. This operation is also called scan.
MP_CONCAT mpc_concat Concatenation (to all tasks) in the group. It is logically equivalent to each task in the group performing a one-to-all broadcast. It is also referred to as completed broadcast or expand.
MP_INDEX mpc_index Each task in a group performs a seatter operation sending a distinct message to all the tasks in the group in order by rank. It is also called multi-scatter, all-to-all personalized communication, or complete exchange.
21~6169 A "decision function" is used to select the communication mode for performing a particular distribution operation. The decision function uses one or more "parameters" to select the communication mode. One type of parameter is a "run-time" parameter which is associated with the particular operation. An example of a run-time parameter associated with a broadcast operation would be the message to be broadcast.
Another type of parameter is a "hardware parameter". An example of a hardware parameter would be "execution speed" of the processor.
Another example would be the "memory move" speed of the processor. This is the speed at which the processor can move values from one location in its memory to another. Memory move speed is a useful metric because certain communication modes require the manipulation of large amounts of data in the processor's memory. In one simple embodiment, the hardware parameters could be obtained at the beginning of the job.
Both types of parameters are used by the decision function in conjunction with certain "predefined relationships", which are incorporated in the computer system's library when developed. Run-time and hardware parameters are employed in defining the relationships.
Each particular operation using each communication mode is described by one of the relationships. Examples of "relationships" include the "time interval required for executing," "computer system traffic generated by," and "work space required for performing" the particular operation using each communication mode.
The relationships are "prioritized" by a library developer to represent some preference in selecting a communication mode. This preference may be to minimize (i.e., optimize) time or work space required for the execution of the operation. The operation is typically executed within a "job" on a computer system. The job may, however, include multiple operations that require the dynamic selection process.
FIG. 2 is a flowchart illustrating one embodiment of the overall process for selecting a technique for a particular task. Initially, a job is started, 200, "JOB STARTS," that requires the use of an operation that may be performed by a plurality of communication modes. A hardware characterization test is then run, 201, "HARDWARE CHARACTERIZATION."
21~616~
This test provides a plurality of hardware parameters that will be used within the decision function that determines which communication mode will be selected. Next, a set of run-time parameters are obtained that will be used in the decision function, 202, "OBTAIN RUN-TIME
PARAMETERS." These parameters may include, for example, a message to be broadcast to a plurality of nodes, or a quantity of nodes for a message to be broadcast to. The decision function, 203, "DECIDE WHICH
MODE," uses the run-time and hardware parameters to decide which communication mode to select. The selected communication mode is then employed, 204, "EXECUTE APPROPRIATE MODE." In another embodiment, the job may include a plurality of identical or different type operations, each requiring the dynamic selection of a communication mode.
As noted briefly above, the dynamic communication mode selection process in accordance with the present invention is based upon many parameters. These parameters are derived from a plurality of sources.
A first source of parameters are hardware parameters of the multinode computer system. For example, in one embodiment, a hardware characterization test is preferably run at the beginning of a job to obtain hardware performance characteristics such as processor execution speed, memory move speed, and network interconnect speed. A flowchart of one embodiment of a hardware characterization process is presented in FIG. 3. This process includes a plurality of tests used to characterize the hardware and obtain hardware parameters.
First, an execution speed test is run, 301, "EXECUTION SPEED TEST."
In this test, the processor executes a series of instructions while the elapsed time is recorded. Next, an array of values is copied within the processor's memory, 302, "MEMORY MOVE SPEED TEST." The elapsed time is again recorded. The time it takes a series of messages to pass between nodes is recorded in a network speed test, 303, "NETWORK SPEED TEST."
The results of the aforementioned tests are returned, 304, "RETURN
PERFORMANCE VALUES," for inclusion in the decision function. In another embodiment of this invention, other tests used to characterize the hardware may be added such as a floating point math performance test.
The method for carrying out these and other hardware characterization 21g61fi9 tests would be obvious to one of ordinary skill in the art.
In a further embodiment, the hardware characterization test may be run on a periodic basis during execution of the job so that the hardware parameters used by the decision function are always representative of the current system. For example, if a job starts at a time when the network is lightly loaded, the hardware parameter associated with computer system traffic would indicate a low traffic level and thus, a fast network connection between processors. At sometime later, however, the computer system traffic may increase resulting in the network becoming congested and, thus, a slower network connectivity. Updating the computer system traffic parameter would allow the selection decision to be more accurate in this instance. Updating may occur every time a decision is to be made, every ten times a decision is to be made, or on any other periodic or non-periodic basis. It is important to note that it would be imprudent to run the hardware characterization test very often because the time taken by the test may use an excessive amount of computer time, thereby degrading overall system performance.
In a further embodiment, the hardware parameter updating may be done dynamically with distribution of each message. For example, a short, 2 or 3 byte, time stamp could be placed at the end of each message greater than a certain length. The length of the message would be chosen so that the additional bytes used by the time stamp do not significantly increase the overall length of the message. In one embodiment, a time stamp may be added to each message greater than 1000 bytes in length. Use of a time stamp enab]es calculation of the time interval required for the associated message to traverse the network.
The calculated time interval may then be used to determine the speed of the network, and to update the computer system traffic parameter.
The second source of parameters used in the decision function is information provided by the application program, for example, contained in a request for a particular operation received from the application program running on a processing node. In the case of a scatter operation, examples include the length of the message (to be distributed), and the number of processing nodes to which the message is _ ` 214616g to be distributed. Relevant parameters for operations currently known, or those yet to be written, would be obvious to one of ordinary skill in the art.
Various characteristics of each communication mode for each operation are described by a predefined relationship or formula. The predefined relationship is defined by the aforementioned run-time and hardware parameters and represents quantities such as the time interval an operation requires to execute, the work space requirements of an operation, and the computer system traffic caused by the operation.
Two examples of communication modes for a broadcast operation are the all-to-all mode and the hypercube mode. The time intervals required by a broadcast operation implemented using the all-to-all and hypercube modes may be easily computed, in addition to other characteristics of these two communication modes. Formulas for calculating time, computer system traffic, and work space requirements are set forth below for both the all-to-all and hypercube modes.
The variables common to the formulas are:
N = Number of nodes;
L = Latency - time required to initiate a transmission;
x = Time required to transmit one byte of data;
m = Message length;
T = Time required to complete the mode;
W = Work space requirements; and S = Computer system traffic.
The time required to complete a communication mode can be expressed:
For hypercube mode broadcast as:
T =llog2Nl( L + mx) 214616g For all-to-all mode broadcast as:
'T= 3 (N-l) (L + NX) The computation of work space requirements for a communication mode can be expressed:
For hypercube mode broadcast as:
W = O
For all-to-all mode broadcast as:
W = O
(Note: Neither of these modes re~uire any work space, others may.) The computation of computer system traffic for a communication mode can be expressed:
For hypercube mode broadcast as:
m (N-l ) For all-to-all mode broadcast as:
mloy2N-~m(N~
The computation of these parameters (and others) for additional broadcast modes will be straightforward for one skilled in the art.
By way of example, a flowchart of one embodiment of a decision function for selecting which communication mode will be used for a broadcast operation is presented in FIG 4. First, a decision is made as 21461~9 to whether the length (m) of the message to be broadcast is very small, 400, "IS m VERY SMALL?" If "yes," then a mode that is known to work well for a broadcast operation of very small messages is chosen, 401, "EXECUTE DEFAULT MODE FOR SMALL MESSAGES." If desired, the preliminary steps 400 and 401 could be excluded from the decision function.
Assuming that the message is not very small, the work space requirements for each communication mode are established, 402 "COMPUTE
WORK SPACE REQUIREMENTS." In this example there are two possible modes, mode 1 and mode 2. A decision is initially made, 403, "MODE 1 FITS?", whether mode 1 will fit into memory. If it will not, then inquiry is made whether mode 2 will fit in memory, 404, "MODE 2 FITS?". If neither mode will fit, then the process is stopped, 405, "STOP." Alternatively, if mode 2 fits in memory, then it is executed, 406, "EXECUTE MODE 2."
Again, this assumes that mode 1 did not fit in memory. If mode 1 did fit in memory then inquiry is made whether mode 2 also fits in memory, 407, "MODE 2 FITS?". If mode 2 does not fit in memory, then mode 1 is executed, 408, "EXECUTE MODE 1." This is because mode 1 is the only viable choice.
If both mode 1 and mode 2 fit into memory, then the time requirements for each mode are computed, 409, "COMPUTE TIME
REQUIREMENTS." Inquiry is made regarding whether there is a significant difference, between the times required for executing the two modes, 410, "IS DIFFERENCE SIGNIFICANT?" A significant difference in time might be a difference greater than five (5) percent. If the difference is significant, then a decision is made whether the time taken by mode 1 (Tl) is less than the time taken by mode 2 (T2), 411, "Tl < T2?". If time Tl is not less than time T2, then mode 2 is executed, 412, "EXECUTE
MODE 2." However, if time Tl is less than time T2, then mode 1 is executed, 413, "EXECUTE MODE 1." Essentially, the object here is to minimize the time needed to perform the broadcast.
If there is no significant difference between the time each mode requires, then a comparison based upon the next most important factor, e.g., computer system traffic, is made. First, the computer system traffic for the two modes is calculated, 414, "COMPUTE NETWORK TRAFFIC."
21~16~
Then, inquiry is made as to whether the network traffic of mode 1 (Sl) is less than the network traffic of mode 2 (S2), 415, "S1 < S2?". If the computer system traffic generated by mode 1 is less, then mode 1 is chosen, 416, "EXECUTE MODE 1," thus minimizing computer system traffic.
Alternatively, if the network traffic caused by mode 1 is greater than that of mode 2, then mode 2 is executed, 417, "EXECUTE MODE 2," again minimizing computer system traffic.
Note from the above discussion, that a preliminary step preferably precedes the full decision function. In this preliminary step (steps 400 and 401), a 'quick' in~uiry is made into whether the complete decision function needs to be executed. If the complete decision function is not needed, then a particular communication mode is automatically chosen, and the decision process is bypassed. For example, if a very short message is to be broadcast, then the time spent in the decision function may be longer than the time it takes to broadcast the message. Performing the complete decision function in such a case would be wasteful. Therefore, default communication mode with good short message performance is automatically chosen.
As a specific hardware embodiment of the invention, the multiple processors could comprise IBM RS/6000 processors, and the network fabric linking the processors could consist of a crossbar switch. In another embodiment, the network fabric might be a local area network, and the processors could comprise IBM PS/2 processors. One skilled in the art will recognize that processor types and network fabric types may vary greatly, and may even be mixed within the same system without departing from the scope of the present invention.
While the invention has been particularly shown and described with reference to a preferred selection method and apparatus embodiment therein, it will be understood by those skilled in the art that various other changes in form and detail may be made without departing from the spirit and scope of the invention. The claims appended hereto are intended to encompass all such modifications.
Claims (50)
1. In a multinode computer system, a method for dynamically selecting one communication mode from a plurality of communication modes for performing a particular operation, said method comprising the steps of:
(a) obtaining a run-time parameter associated with the particular operation; and (b) selecting one communication mode from the plurality of communication modes using said associated run-time parameter.
(a) obtaining a run-time parameter associated with the particular operation; and (b) selecting one communication mode from the plurality of communication modes using said associated run-time parameter.
2. The method of claim 1, wherein said selecting step (b) includes employing said associated run-time parameter in a predefined decision function to select said one communication mode from said plurality of communication modes.
3. The method of claim 2, further comprising the step of creating said predefined decision function, said step of creating including employing at least one predefined relationship in said predefined decision function.
4. The method of claim 3, wherein said step of creating includes employing a predefined time relationship, said predefined time relationship comprising a time interval relationship for performing the particular operation using the selected one communication mode.
5. The method of claim 3, wherein said step of creating includes employing a predefined traffic relationship, said predefined traffic relationship comprising a relationship definitive of computer system traffic generated by performing the particular operation using the selected one communication mode.
6. The method of claim 3, wherein said step of creating includes employing a predefined work space relationship, said predefined work space relationship comprising a relationship definitive of a work space amount required for performing the particular operation using the selected one communication mode.
7. The method of claim 3, wherein said step of creating includes employing a plurality of predefined relationships in said predefined decision function, and wherein said step of creating further comprises prioritizing for said predefined decision function each predefined relationship of said plurality of predefined relationships.
8. The method of claim 7, wherein said step of prioritizing said plurality of predefined relationships includes prioritizing said plurality of predefined relationships to minimize a time interval required for performing the particular operation using the selected one communication mode.
9. The method of claim 7, wherein said step of prioritizing said plurality of predefined relationships includes prioritizing said plurality of predefined relationships to minimize computer system traffic generated by performing the particular operation using the selected one communication mode.
10. The method of claim 7, wherein said step of prioritizing said plurality of predefined relationships includes prioritizing said plurality of predefined relationships to minimize work space required for performing the particular operation using the selected one communication mode.
11. The method of claim 1, wherein said obtaining step (a) includes obtaining a message length associated with the particular operation.
12. The method of claim 1, wherein said obtaining step (a) includes obtaining a number of processing nodes in said multinode computer system associated with the particular operation.
13. The method of claim 1, further comprising the step of obtaining a hardware parameter of the computer system, and wherein said selecting step (b) includes selecting the one communication mode from the plurality of communication modes using said obtained run-time parameter associated with the particular operation and said obtained hardware parameter of the computer system.
14. The method of claim 13, wherein said computer system has an execution speed, and wherein said step of obtaining the hardware parameter comprises the step of obtaining the execution speed of said computer system.
15. The method of claim 13, wherein said computer system has a memory move speed, and wherein said step of obtaining the hardware parameter comprises the step of obtaining the memory move speed of the computer system.
16. The method of claim 13, wherein the computer system has a network communication speed, and wherein said step of obtaining the hardware parameter comprises obtaining the network communication speed of said computer system.
17. The method of claim 13, wherein said particular operation exists within a job to be executed within the computer system, and wherein said obtaining of the hardware parameter includes obtaining the hardware parameter of the computer system upon initialization of said job within the computer system.
18. The method of claim 17, wherein said particular operation occurs multiple times within said job, and wherein said obtaining of the hardware parameter includes obtaining the hardware parameter of the computer system with each occurrence of the particular operation within the job.
19. The method of claim 17, wherein the particular operation occurs multiple times within the job, and wherein said obtaining of the hardware parameter includes periodically obtaining the hardware parameter of the computer system during execution of the job within the computer system.
20. The method of claim 17, wherein said selecting step (b) includes selecting said communication mode from said plurality of communication modes during execution of said job within the computer system.
21. The method of claim 1, wherein said plurality of communication modes includes an all-to-all scatter pattern communication mode and a hypercube communication mode.
22. The method of claim 1, wherein said selecting step (b) includes selecting said one communication mode from said plurality of communication modes using said associated run-time parameter to optimize a performance characteristic of the computer system.
23. In a multinode computer system, a method for performing a particular operation employing a selected communication mode, said method comprising the steps of:
(a) selecting one communication mode of communication from a plurality of modes of communication for performing the particular operation so as to optimize a performance characteristic of the multinode computer system; and (b) performing the particular operation within the multinode computer system using the selected one communication mode of communication of said step (a).
(a) selecting one communication mode of communication from a plurality of modes of communication for performing the particular operation so as to optimize a performance characteristic of the multinode computer system; and (b) performing the particular operation within the multinode computer system using the selected one communication mode of communication of said step (a).
24. The method of claim 23, wherein said selecting step (a) includes obtaining a run-time parameter associated with the particular operation.
25. The method of claim 24, wherein said selecting step (a) further includes employing said run-time parameter in a predefined decision function to select said one communication mode from said plurality of communication modes.
26. The method of claim 25, further comprising the step of creating said predefined decision function, said step of creating including employing at least one predefined relationship in said predefined decision function.
27. The method of claim 26, wherein said step of creating said predefined decision function includes employing one of (i) a predefined time relationship for performing the particular operation using the selected one communication mode, (ii) a relationship definitive of computer system traffic generated by performing the particular operation using the selected one communication mode, and (iii) a relationship definitive of work space amount required for performing the particular operation using the selected one communication mode.
28. The method of claim 26, wherein said step of creating includes employing a plurality of predefined relationships in said predefined decision function, and wherein said step of creating further comprises prioritizing for said predefined decision function each predefined relationship of said plurality of predefined relationships.
29. The method of claim 28, wherein said step of prioritizing said plurality of predefined relationships includes prioritizing said plurality of predefined relationships to minimize one of (i) time required for performing the particular operation employing the selected one communication mode, (ii) computer system traffic generated by performing the particular operation using the selected one communication mode, and (iii) work space required for performing the particular operation using the selected one communication mode.
30. The method of claim 24, wherein said selecting step (a) includes obtaining a message length for the particular operation as the run-time parameter associated with the particular operation.
31. The method of claim 24, wherein said selecting step (a) includes obtaining a number of nodes of said multinode computer system associated with the particular operation as the run-time parameter.
32. The method of claim 23, wherein said selecting step (a) further comprises obtaining a hardware parameter of the computer system and employing the hardware parameter in selecting the one communication mode from the plurality of communication modes.
33. The method of claim 32, wherein said particular operation occurs within a job to be executed within the computer system, and wherein said obtaining of the hardware parameter includes obtaining the hardware parameter of the computer system upon initialization of said job within the computer system.
34. The method of claim 33, wherein the particular operation occurs multiple times within the job, and wherein said obtaining of the hardware parameter associated with the computer system includes obtaining the hardware parameter of the computer system upon each occurrence of the particular operation within the job.
35. The method of claim 33, wherein said step of obtaining the hardware parameter of the computer system comprises one of (i) obtaining an execution speed of the computer system, (ii) obtaining a memory move speed of the computer system, and (iii) obtaining a network communication speed of the communication system.
36. A multinode computer system for performing a particular operation, said multinode computer system comprising:
means for obtaining a run-time parameter associated with the particular operation; and means for selecting one communication mode from a plurality of communication modes using the associated run-time parameter.
means for obtaining a run-time parameter associated with the particular operation; and means for selecting one communication mode from a plurality of communication modes using the associated run-time parameter.
37. The multinode computer system of claim 36, wherein said means for selecting includes means for employing said associated run-time parameter in a predefined decision function to select said one communication mode from said plurality of communication modes.
38. The multinode computer system of claim 37, further comprising means for storing said predefined decision function.
39. The multinode computer system of claim 36, wherein said means for obtaining comprises means for obtaining a message length associated with the particular operation.
40. The multinode computer system of claim 36, wherein said means for obtaining comprises means for obtaining a number of processing nodes in said multinode computer system associated with the particular operation.
41. The multinode computer system of claim 36, further comprising means for obtaining a hardware parameter of the computer system, and wherein said means for selecting includes means for selecting the one communication mode from the plurality of communication modes using the obtained run-time parameter associated with the particular operation and the obtained hardware parameter of the computer system.
42. The multinode computer system of claim 41, wherein said means for obtaining the hardware parameter comprises means for obtaining an execution speed of the computer system.
43. The multinode computer system of claim 41, wherein said means for obtaining the hardware parameter comprises means for obtaining a memory move speed of the computer system.
44. The multinode computer system of claim 41, wherein the particular operation exists within a job to be executed within the computer system, and wherein said means for obtaining the hardware parameter includes means for obtaining the hardware parameter of the computer system upon initialization of the job within the computer system.
45. The multinode computer system of claim 44, wherein said particular operation occurs multiple times within said job, and wherein said means for obtaining the hardware parameter comprises means for obtaining the hardware parameter of the computer system with each occurrence of the particular operation within the job.
46. A multinode computer system of claim 44, wherein the particular operation occurs multiple times within the job, and wherein said means for obtaining the hardware parameter includes means for periodically obtaining the hardware parameter of the computer system during execution of the job within the computer system.
47. The multinode computer system of claim 44, wherein said means for selecting comprises means for selecting the communication mode from the plurality of communication modes during execution of the job within the computer system.
48. The multinode computer system of claim 36, wherein the plurality of communication modes includes an all-to-all scatter pattern communication mode and a hypercube communication mode.
49. The multinode computer system of claim 36, wherein said means for selecting includes means for selecting the one communication mode from the plurality of communication modes using the associated run-time parameter to optimize a performance characteristic of the computer system.
50. The multinode computer system of claim 36, further comprising means for performing the particular operation within the multinode computer system using the selected one communication mode.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US22333994A | 1994-04-05 | 1994-04-05 | |
| US223,339 | 1994-04-05 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2146169A1 CA2146169A1 (en) | 1995-10-06 |
| CA2146169C true CA2146169C (en) | 2001-06-05 |
Family
ID=22836080
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002146169A Expired - Fee Related CA2146169C (en) | 1994-04-05 | 1995-04-03 | Method and system for dynamically selecting a communications mode |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US5742499A (en) |
| EP (1) | EP0676693B1 (en) |
| JP (1) | JPH07282026A (en) |
| AT (1) | ATE195824T1 (en) |
| CA (1) | CA2146169C (en) |
| DE (1) | DE69518453T2 (en) |
Families Citing this family (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6424870B1 (en) * | 1996-02-09 | 2002-07-23 | Hitachi, Ltd. | Parallel processor |
| US5909368A (en) * | 1996-04-12 | 1999-06-01 | Fisher-Rosemount Systems, Inc. | Process control system using a process control strategy distributed among multiple control elements |
| US6035240A (en) * | 1998-11-12 | 2000-03-07 | Moorehead; Jack | Flexible distributed processing system for sensor data acquisition and control |
| JP4008162B2 (en) * | 1999-08-18 | 2007-11-14 | 富士通株式会社 | Communication method and communication apparatus |
| US7624063B1 (en) | 2003-09-30 | 2009-11-24 | Trading Technologies International, Inc. | System and method for improved distribution of market information |
| US20060130042A1 (en) * | 2004-12-15 | 2006-06-15 | Dias Daniel M | Method and apparatus for dynamic application upgrade in cluster and grid systems for supporting service level agreements |
| JP4781139B2 (en) * | 2006-03-20 | 2011-09-28 | キヤノン株式会社 | COMMUNICATION DEVICE AND ITS CONTROL METHOD |
| US7856505B2 (en) | 2007-06-29 | 2010-12-21 | Microsoft Corporation | Instantiating a communication pipeline between software |
| US20090228407A1 (en) * | 2008-03-05 | 2009-09-10 | The Boeing Company | Distributed cognitive architecture |
| JP5347772B2 (en) * | 2009-07-01 | 2013-11-20 | 富士通株式会社 | Transfer rate setting method, data transfer apparatus, and information processing system |
| JP5540694B2 (en) * | 2009-12-22 | 2014-07-02 | 日本電気株式会社 | Parallel computer, computer, communication method and program |
| US9853860B2 (en) | 2015-06-29 | 2017-12-26 | International Business Machines Corporation | Application hierarchy specification with real-time functional selection |
| US11784930B2 (en) | 2021-04-30 | 2023-10-10 | Bank Of America Corporation | Communication system with auto-routing and load balancing |
| US11792108B2 (en) | 2021-04-30 | 2023-10-17 | Bank Of America Corporation | Dynamic auto-routing and load balancing for communication systems |
| US11469988B1 (en) | 2021-04-30 | 2022-10-11 | Bank Of America Corporation | Communication analysis for dynamic auto-routing and load balancing |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4247892A (en) * | 1978-10-12 | 1981-01-27 | Lawrence Patrick N | Arrays of machines such as computers |
| US4750116A (en) * | 1985-10-11 | 1988-06-07 | International Business Machines Corporation | Hardware resource management |
| US4766534A (en) * | 1986-10-16 | 1988-08-23 | American Telephone And Telegraph Company, At&T Bell Laboratories | Parallel processing network and method |
| JPS6424540A (en) * | 1987-07-20 | 1989-01-26 | Sanyo Electric Co | Mixed mode communication terminal equipment |
| US5101498A (en) * | 1987-12-31 | 1992-03-31 | Texas Instruments Incorporated | Pin selectable multi-mode processor |
| US5218676A (en) * | 1990-01-08 | 1993-06-08 | The University Of Rochester | Dynamic routing system for a multinode communications network |
| US5426674A (en) * | 1990-02-06 | 1995-06-20 | Nemirovsky; Paul | Method and computer system for selecting and evaluating data routes and arranging a distributed data communication network |
| DE69029515D1 (en) * | 1990-06-28 | 1997-02-06 | Ibm | Message processing in a data processing device |
| JP2753123B2 (en) * | 1990-08-28 | 1998-05-18 | 富士通株式会社 | Control mode selectable communication controller |
| US5367636A (en) * | 1990-09-24 | 1994-11-22 | Ncube Corporation | Hypercube processor network in which the processor indentification numbers of two processors connected to each other through port number n, vary only in the nth bit |
| JPH04186469A (en) * | 1990-11-21 | 1992-07-03 | Hitachi Ltd | Load test system for multiprocessor system |
| EP0506135A3 (en) * | 1991-03-29 | 1993-11-03 | Ibm | Multi-sender/switching apparatus for status reporting over unbuffered asynchronous multi-stage networks |
| US5265239A (en) * | 1991-04-08 | 1993-11-23 | Ardolino Anthony A | Method for remotely accessing service programs of a local processing system supporting multiple protocol stacks and multiple device drivers |
| JP2930257B2 (en) * | 1991-04-22 | 1999-08-03 | 株式会社東芝 | Portable electronic devices |
| JPH05342172A (en) * | 1992-06-08 | 1993-12-24 | Toshiba Corp | Multiprocessor system |
-
1995
- 1995-01-25 EP EP95100958A patent/EP0676693B1/en not_active Expired - Lifetime
- 1995-01-25 AT AT95100958T patent/ATE195824T1/en not_active IP Right Cessation
- 1995-01-25 DE DE69518453T patent/DE69518453T2/en not_active Expired - Fee Related
- 1995-01-31 JP JP7014039A patent/JPH07282026A/en active Pending
- 1995-04-03 CA CA002146169A patent/CA2146169C/en not_active Expired - Fee Related
-
1996
- 1996-07-22 US US08/681,200 patent/US5742499A/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US5742499A (en) | 1998-04-21 |
| EP0676693B1 (en) | 2000-08-23 |
| CA2146169A1 (en) | 1995-10-06 |
| ATE195824T1 (en) | 2000-09-15 |
| DE69518453T2 (en) | 2001-05-23 |
| DE69518453D1 (en) | 2000-09-28 |
| EP0676693A3 (en) | 1996-02-14 |
| JPH07282026A (en) | 1995-10-27 |
| EP0676693A2 (en) | 1995-10-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2146169C (en) | Method and system for dynamically selecting a communications mode | |
| Barak et al. | A distributed load‐balancing policy for a multicomputer | |
| US5659701A (en) | Apparatus and method for distributed program stack | |
| US5748959A (en) | Method of conducting asynchronous distributed collective operations | |
| FI90475C (en) | Real-time distributed database processing system | |
| EP0667011B1 (en) | Data processing system and operating system | |
| US6393455B1 (en) | Workload management method to enhance shared resource access in a multisystem environment | |
| Sinha et al. | A load balancing strategy for prioritized execution of tasks | |
| US6078945A (en) | Operating system for use with computer networks incorporating two or more data processors linked together for parallel processing and incorporating improved dynamic load-sharing techniques | |
| US5526491A (en) | System and method for calling selected service procedure remotely by utilizing conditional construct switch statement to determine the selected service procedure in common stub procedure | |
| CN111176801B (en) | Multi-process management method, device, equipment and storage medium | |
| KR19990042176A (en) | How to Boot a Node on a High-Speed Parallel Computer | |
| KR0163229B1 (en) | Resource allocation synchronization in a parallel processing system | |
| JP3429582B2 (en) | Multiprocessor system | |
| CN116069447A (en) | Virtual machine NUMA topology generation method, device, equipment and medium | |
| JPH0883257A (en) | Method for optimizing process execution of parallel computer system | |
| Xu et al. | Dynamic load balancing for parallel program execution on a message-passing multicomputer | |
| EP0509946A2 (en) | Apparatus and method for implementing a distributed program stack | |
| CN112597502B (en) | Large-scale computing service configuration method and system based on trusted cloud | |
| JP3763452B2 (en) | Information processing system, object priority management method, operating system, and recording medium | |
| Espinosa et al. | Integrating automatic techniques in a performance analysis session | |
| KR100241356B1 (en) | Multilevel scheduling structure for dynamic synchronization in distributed system | |
| Hempel | ‘The ANL/GMD Macros (PARMACS) in Fortran for Portable Parallel Programming using the Message Passing Programming Model | |
| JPH08194612A (en) | Method and system for controlling program execution | |
| JP2000295353A (en) | Autonomously cooperative distributed processing type management information system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |