| Table of Contents |
|---|
General Descrikption
The Argon HPC system is the latest HPC system of the University of Iowa. It consists of 366 compute nodes running CentOS-7.4 Linux. There are several compute node configurations,
- 56-core 128GB
- 56-core 256GB
- 56-core 512GB
- 40-core 96GB
- 40-core 192GB
The Argon cluster is split between two data centers,
- ITF → Information Technology Facility
- LC→ Lindquist Center
There are 22 machines with Nvidia P100 accelerators, 2 machines with Nvidia K80 accelerators, 2 machines with Nvidia P40 accelerators, 13 machines with 1080Ti accelerators, and 16 machines with Titan V accelerators.
...
The Rpeak (theoretical Flops) is 385.0 TFlops, not including the accelerators, with 89.7 TB of memory. In addition, there are 2 login nodes of the Broadwell system architecture. The login nodes have , with 256GB of memory each.
While on the backend Argon is a completely new architecture, the frontend should be very familiar to those who have used previous generation HPC systems at the University of Iowa. There are, however, a few key differences that will be discussed in this page.
Hyperthreaded Cores (HT)
One important difference between Argon and previous systems is that Argon has Hyperthreaded processor cores turned on. Hyperthreaded cores can be thought of as splitting a single processor into two virtual cores, much as a Linux process can be split into threads. That oversimplifies it but if your application is multithreaded then hyperthreaded cores can potentially run the application more efficiently. For non-threaded applications you can think of any pair of hyperthreaded cores to be roughly equivalent to two cores at half the speed if both cores of the pair are in use. This can help ensure that the physical processor is kept busy for processes that do not always use the full capacity of a core. The reasons for enabling HT for Argon are to try to increase system efficiency on the workloads that we have observed. There are some thing to keep in mind as you are developing your workflows.
...
If your job does not use the system openmpi, or does not use MPI, then any desired core binding will need to be set up with whatever mechanism the software uses. Otherwise, there will be no core binding. Again, that may not be a major issue. If your job does not work well with HT then run on a number of cores equal to half of the number of slots requested and the OS scheduler will minimize contention.
new SGE utilities
While SoGE is very similar to previous versions of SGE there are some new utilities that people may find of interest. There are manual pages for each of these.
...
The Argon cluster is a heterogeneous cluster, meaning that it consists of different node types with varying amounts and types of resources. There are many resources that SGE keeps track of and most of them can be used in job submissions. However, the resource designations for machines based on CPU type, memory amount, and GPU are more likely to be used in practice. Note that there can be very different performance characteristics for different types of GPUs and CPUs. In additionAs noted above, the Argon cluster is split between two data centers,
- ITF → Information Technology Facility
- LC→ Lindquist Center
The As we expand the capacity of the cluster the datacenter selection could be important for multi node jobs, such as those that use MPI, that require a high speed interconnect fabric. The compute nodes used in those job would need to be in the same data center.
| Info |
|---|
All Currently, all nodes with the OmniPath fabric are located in the LC datacenter. All nodes that have the |
The investor queues will have a more limited variability in machine types. However, the all.q queue contains all machines and when running jobs in that queue it may be desirable to request specific machine types. The following table lists the options for the more common resource requests. They would be selected with the '-l resource' flag to qsub.
...