| Dror G. Feitelson, Anat Batat, Gabriel Benhanokh, David Er-E1, Yoav Etsion, Avi Kavas, Tomer Klainer, Uri Lublin, and Marc Volovic. The ParPar System: a Soft- ware MPP. In Rajkumar Buyya, editor, High Performance Cluster Computing, volume 1: Architectures and systems, pages 754-770. Prentice-Hall, 1999. |
....for it. Parpar s modular design could possibly oer simple integration of some of its components in RMS to allow comparison of implemen tation choices between the two schedulers, or as a shortcut to implementing features in RMS. For a more detailed view of Parpar, the reader is referred to [1, 9, 14]. 15 3 Technical Description of RMS 3.1 Overview In this section we describe various technical aspects of RMS, and in particular those that are relevant to job scheduling. We do not intend to use RMS for our prototype implementation except for the initial launching of processes. Therefore, it ....
Dror G. Feitelson, Anat Batat, Gabriel Benhanokh, David Er-E1, Yoav Etsion, Avi Kavas, Tomer Klainer, Uri Lublin, and Marc Volovic. The ParPar System: a Soft- ware MPP. In Rajkumar Buyya, editor, High Performance Cluster Computing, volume 1: Architectures and systems, pages 754-770. Prentice-Hall, 1999.
.... Manager or NM (one daemon per compute node) and the Program Launcher or PL (several daemons per compute node) The MM is in charge of resource allocation for jobs (both in space and time) Whenever a new job arrives, the MM queues it and tries to allocate PEs to it (using a buddy tree algorithm [11, 12]) If the scheduling policy allows for multiprogramming (e.g. GS) the PEs are allocated in any time slot that has enough available resources. After a successful allocation, the MM broadcasts a job launch message to all the NMs, and those NMs on nodes that are allocated to the job will launch it ....
Dror G. Feitelson, Anat Batat, Gabriel Benhanokh, David Er-El, Yoav Etsion, Avi Kavas, Tomer Klainer, Uri Lublin, and Marc Volovic. The ParPar System: a Software MPP. In Rajkumar Buyya, editor, High Performance Cluster Computing, volume 1: Architectures and systems, pages 754--770. Prentice-Hall, 1999.
....Launcher (PL) Table 2 describes the distribution and location of each of these. The MM is in charge of resource allocation for jobs, including both space and time resources. Whenever a new job arrives, the MM enqueues it and attempts to allocate processors to it using a buddy tree algorithm [11, 12]. Global process scheduling decisions are made by the MM. NMs are responsible for managing resources on a single node (which is typically an SMP) NMs are involved in finding available PLs for a job launch, receiving files transfered by the MM, scheduling and descheduling local processes, and ....
Dror G. Feitelson, Anat Batat, Gabriel Benhanokh, David Er-El, Yoav Etsion, Avi Kavas, Tomer Klainer, Uri Lublin, and Marc Volovic. The ParPar system: A software MPP. In Rajkumar Buyya, editor, High Performance Cluster Computing, volume 1: Architectures and Systems, pages 758-- 774. Prentice-Hall, 1999. ISBN 0-13-013784-7. Available from http://www.cs.huji.ac.il/ labs/parallel/chap.ps.gz.
....through explicit synchronization and are not coordinated by a central controller. In particular, the network is not flushed during a context switch; therefore, a node may receive a packet that is addressed to a process that is no longer running. To address this problem, the CM5 [10] ParPar[3], and SCore D[5] propose network flushing mechanisms. In the CM 5, during a context switch, all packets are dropped down to the closest node in the fat tree network and stored temporarily. When the job is rescheduled, these packets are reinjected to complete their trip. In the ParPar ....
Dror G. Feitelson, Anat Batat, Gabriel Benhanokh, David Er-El, Yoav Etsion, Avi Kavas, Tomer Klainer, Uri Lublin, and Marc Volovic. The ParPar System: a Software MPP. In Rajkumar Buyya, editor, High Performance Cluster Computing, volume 1: Architectures and systems, pages 754--770. Prentice-Hall, 1999.
....for it. Parpar s modular design could possibly o er simple integration of some of its components in RMS to allow comparison of implementation choices between the two schedulers, or as a shortcut to implementing features in RMS. For a more detailed view of Parpar, the reader is referred to [1, 9, 14]. 15 3 Technical Description of RMS 3.1 Overview In this section we describe various technical aspects of RMS, and in particular those that are relevant to job scheduling. We do not intend to use RMS for our prototype implementation except for the initial launching of processes. Therefore, it ....
Dror G. Feitelson, Anat Batat, Gabriel Benhanokh, David Er-El, Yoav Etsion, Avi Kavas, Tomer Klainer, Uri Lublin, and Marc Volovic. The ParPar System: a Software MPP. In Rajkumar Buyya, editor, High Performance Cluster Computing, volume 1: Architectures and systems, pages 754770. Prentice-Hall, 1999.
....The matching of processes is based on a prediction of what their CPU utilization will be in the next quantum. 2.1 Framework for Scheduling The framework for paired gang scheduling is depicted in Figure 2. We use a centralized gang scheduler, as is used in many conventional implementations [4, 9, 5, 8]. This is a user level daemon process that runs on a distinguished node in the cluster. It maintains information in an Ousterhout matrix [14] in which rows denote scheduling slots and columns represent processors. In strict gang scheduling, one row is selected each time. Each node scheduler is ....
....to run two processes. If no alternates are found, only one process will run. A node will remain idle only if it is not allocated in both selected slots. 3 Implementation 3. 1 The ParPar Environment The implementation of paired gang scheduling was done in the context of the ParPar cluster [4]. The cluster has a host node which is the master and 16 other nodes which are the slaves . The master runs a daemon which controls all system wide activity. Among other things, it decides for the slaves when they should do a context switch. The master also maintains the gang scheduling matrix. ....
Feitelson D. G., Batat A., Benhanokh G., Er-El D., Etsion Y., Kavas A., Klainer T., Lublin U., and Volovic M. A., The ParPar system: a software MPP. In High Performance Cluster Computing, Vol. 1: Architectures and Systems, Rajkumar Buyya (Ed.), pp. 754--770, Prentice-Hall, 1999.
....situation is not so rosy if jobs always used the exact amount of memory indicated in their executable, the predictions would always be perfect. 3. Scheduler Implementation The idea of queueing jobs that do not have enough memory available was implemented in the framework of the ParPar system [4]. This section first describes the system, and then the implementation of the memory considerations. 3.1. The ParPar system The ParPar prototype cluster is built from 17 PCs: A host and 16 nodes. The PCs have an Intel Providence motherboard with a Pentium Pro 200 processor, 64 MB DRAM, and a 2.1 ....
D. G. Feitelson, A. Batat, G. Benhanokh, D. Er-El, Y. Etsion, A. Kavas, T. Klainer, U. Lublin, and M. A. Volovic, "The ParPar system: a software MPP ". In High Performance Cluster Computing, Vol. 1: Architectures and Systems, R. Buyya (ed.), pp. 754--770, Prentice-Hall, 1999.
....large time quantum (measured in seconds or even minutes) and the communication buffers size is measured in megabytes, the overhead incurred by the buffer copying does not affect performance. 2. System Background 2.1. The ParPar Cluster The configuration of our cluster system, the ParPar [4], is based on 17 Pentium Pro computers, running BSDI 3.1. These are connected by a 10MB switched Ethernet that serves for control functions, and a 1.28GB Myrinet [1] for data communications. The Myrinet network interface cards have a LANai 4.3 processor and 512 KB RAM. Data communications use a ....
D. G. Feitelson, A. Batat, G. Benhanokh, D. Er-El, Y. Etsion, A. Kavas, T. Klainer, U. Lublin, and M. A. Volovic, "The ParPar system: a software MPP ". In High Performance Cluster Computing, Vol. 1: Architectures and Systems, R. Buyya (ed.), pp. 754--770, Prentice-Hall, 1999.
....cluster (Fig. 1) The central controller is responsible for configuration management, resource allocation, and job control. The per node processes collect local data and implement the decisions of the central controller. Example systems based on this design include the Berkeley NOW [23] and ParPar [19]. The next section presents a survey of system features that are needed in order to implement such a structure. These include communication facilities used among the different processes, and facilities to spawn and control user processes. In some cases, it is possible to spawn processes remotely ....
....contains the process management, memory management, file system and the rest. Many clusters have been built based on Linux or other Unix variants. Examples include the Berkeley NOW [23] the LosLobos Supercluster (http: www.ahpcc.unm.edu Systems Hardware LosLobos ) Beowulf [36] and ParPar [19]. QNX is a real time commercial operating system, developed by QNX Software Systems. The QNX real time operating system provides applications with a network distributed, real time environment that delivers nearly the full device level performance of the underlying hardware. The architecture ....
D. G. Feitelson, A. Batat, G. Benhanokh, D. Er-El, Y. Etsion, A. Kavas, T. Klainer, U. Lublin, and M. A. Volovic, "The ParPar system: a software MPP ". In High Performance Cluster Computing, Vol. 1: Architectures and Systems, R. Buyya (ed.), pp. 754--770, Prentice-Hall, 1999.
....seconds or even minutes) and the communication bu ers size is measured in megabytes, the overhead incurred by the bu er copying algorithm does not a ect performance, as we shall see in Section 4.2. 2 2 System Background 2. 1 The ParPar Cluster The basic design of our cluster system, the ParPar [4], is simple. The hardware consists of 17 Pentium Pro computers, running BSDI 3.1, connected by a control network which is a 10MB switched Ethernet, and a dedicated data network a 1.28GB Myrinet [1] The data network uses a modi ed version of the FM 2.0 library from the University of Illinois ....
D. G. Feitelson, A. Batat, G. Benhanokh, D. Er-El, Y. Etsion, A. Kavas, T. Klainer, U. Lublin, and M. A. Volovic, \The ParPar system: a software MPP". In High Performance Cluster Computing, Vol. 1: Architectures and Systems, R. Buyya (ed.), pp. 754{ 770, Prentice-Hall, 1999.
....[24] To integrate FM with the ParPar system, the daemons used by FM to set up its environment (GRM and CM) were replaced by functions in the ParPar daemons. This was relatively straightforward, as the required data such as job ID and logical node numbers exists in the ParPar system anyway [14]. The only addition was an API that passes the data to the communication subsystem. The details are described elsewhere [13] Routing in FM is static. Upon initialization, nodes read a configuration file that describes the network topology. They then compute minimal paths from each node to all ....
D. G. Feitelson, A. Batat, G. Benhanokh, D. Er-El, Y. Etsion, A. Kavas, T. Klainer, U. Lublin, and M. A. Volovic, "The ParPar system: a software MPP". In High Performance Cluster Computing, Vol. 1: Architectures and Systems, R. Buyya (ed.), pp. 754--770, Prentice-Hall, 1999. 19
....of service to all the system s users [11] This allocation of resources is done by a central operating system which runs on a host that manages the whole system. The system scheduler determines when and on which nodes a job will be executed. One way of scheduling parallel jobs is gang scheduling [7]. Its main idea is to map the threads of a parallel job to distinct processors, and then schedule them to be executed simultaneously on their respective processors. Thus, they either all run at once or none do. Using time slicing allows for interactive response times. The fact that all threads run ....
....situation is not so rosy if jobs always used the exact amount of memory indicated in their executable, the predictions would always be perfect. 3 Scheduler Implementation The idea of queueing jobs that do not have enough memory available was implemented in the framework of the ParPar system [7]. This section first describes the system, and then the implementation of the memory considerations. 3.1 The ParPar system 3.1.1 Hardware The ParPar prototype cluster is built from 17 PCs: A host called parpar and 16 nodes named from par1 to par16 (Figure 4) The PCs have an Intel ....
D. G. Feitelson, A. Batat, G. Benhanokh, D. Er-El, Y. Etsion, A. Kavas, T. Klainer, U. Lublin, and M. A. Volovic, "The ParPar system: a software MPP ". In High Performance Cluster Computing, Vol. 1: Architectures and Systems, R. Buyya (ed.), pp. 754--770, Prentice-Hall, 1999.
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC