MANAGING SLAAC RRP CLUSTERS Sample Clauses

MANAGING SLAAC RRP CLUSTERS. In addition to the single-processor single-accelerator per job programming model as described above, some DoD applications require more logic and/or memory than a single FPGA accelerator board can provide, and consequently require multiple boards to operate simultaneously. The SLAAC ACS API facilitates this by allowing multiple FPGA boards to work data-synchronously using FIFO channels over a local system bus or high-speed network. The Research Reference Platform (RRP) shown at right is a cluster of FPGA-accelerated workstations on a Myrinet gigabit network. The FPGA boards used in the RRP include SLAAC- 1, SLAAC-1V, WildForce™, and WildStar™. The entire system is controlled by a single host program, using the SLAAC API. This task will investigate techniques for managing and scheduling jobs on these cooperative clusters. From the point of view of the naive job scheduler, the entire cluster is visible as a single node. The only difference between this cluster node and regular nodes based on a single accelerator board is a substantially greater computational power. However, the big difference between computational resources of RRP and other FPGA- accelerated workstations may cause additional challenges in job scheduling. For example, the RRP is naturally very well suited for large time-consuming jobs, but may be inappropriate for small tasks. Small tasks would incur the same setup and task management overhead as large tasks yet underutilize the compute resources available using the naive approach. A more efficient approach is to partition the cluster as needed for the available tasks. We will investigate the feasibility and performance characteristics of sharing RRP among a large set of small independent jobs. Scheduling tasks on cooperative computational clusters brings a number of challenges in addition to the benefits. Introducing RRP as a computational node, allows the users to execute very complex tasks reserved traditionally for supercomputers. These applications often exploit massive amounts of parallelism inherent in these systems. In particular, RRP supports inter- process communication, based on MPI. Cluster applications may have complex data movement patterns among individual nodes, where I/O performance can have a significant effect on overall application performance. Unforeseen performance degradation can occur unless I/O is taken into account during task scheduling. The daemon operation will be substantially more complicated in the case of the ...