Programs you can run on the clusters may either be pre-compiled binaries that have been built and linked on another compatible GPU system or ones you have written yourself (or using source code given to you by others) as a CUDA source file and compiled using the nvcc compiler. By convention, CUDA source files have the suffix .cu but may contain a mix of C, C++ and CUDA statements; nvcc uses the system's gcc compiler to generate non-GPU object code when necessary, switching automatically to the nVidia PTX compiler for GPU object code.
Getting started
- Access to the GPU servers is remotely via ssh and to begin with, you need an account on one or more of the servers - simply email Andy Thomas requesting an account. Once this is set up, the account details will be mailed to you - the password is a random password and you are strongly encouraged to change it when you log in for the first time, using the 'passwd' utility and following the prompts.
- nvcc does have a man page on the server but it's not very useful since it just lists the main nVidia CUDA utilities with very little information on their usage. You'll find a selection of nVidia documentation in PDF format right here on this server and you can also access nVidia's own online documentation for full information on the CUDA Toolkit.
Checking the status of the GPUs
- If you want to find out what all the GPU cards are doing, you can use either the gpustat or the nvidia-smi utilities. Most users will prefer using gpustat -simply type 'gpustat' in a login session and you should be greeted by a screenful of information like this example:
For in-depth information, use the nvidia-smi utility - this has a huge number of options too long to go into here but the man page (type 'man nvidia-smi' to see this) describes these in detail and typing 'nvidia-smi' with no parameters produces a summary of the GPU cards' status as shown below:
- which shows both GPUs in nvidia2 fully loaded although only using about 20% of the total available memory; the PIDs and names of the processes running on the host server are also listed and normal Linux utilities such as 'ps ax' can be used to find further information on these.
- Typing 'nvidia-smi -q' produces a very detailed status report for all GPUs in the system but this can be limited to a given GPU of interest with the -i N option, where N is the GPU identifier (0,1 or 2 for nvidia1 and 0 or 1 for nvidia2 and so on). For example, the command
nvidia-smi -q -i 1
- will show the full information for GPU 1 only. Unlike most other nVidia CUDA programs, nvidia-smi has extensive man page documentation although many of the available options are reserved for the root user since they affect the operation of the GPU card.
- which shows both GPUs in nvidia2 fully loaded although only using about 20% of the total available memory; the PIDs and names of the processes running on the host server are also listed and normal Linux utilities such as 'ps ax' can be used to find further information on these.
Are disk quotas imposed on the GPU cluster servers?
- No but as with all Maths systems disk usage is continuously monitored and those who have used a large proportion of the available home directory storage will be asked to move data to one of the silo storage servers, to clustor or clustor2 or delete unwanted data, etc.
Is user data on the cluster servers backed up?
- Yes, all four servers are mirrored daily to our onsite backup servers which in turn are mirrored to the Maths offsite servers in Milton Keynes and Slough.
What about job scheduling and fair usage controls?
- Job queueing and resource management is not being used on the GPU clusters or the stand-alone servers at present because, unlike the Maths compute cluster in the past, fair usage and contention for resources has not been a problem with the GPU facilities to date. Also, it is very difficult to implement traditional HPC-style cluster job management on GPU cards because there is no low-level interface to core and memory resources on any given GPU card, although it is possible to control use of entire GPU cards. But with the present small-scale clusters used by a small group of regular users, it currently is not worth implementing any form of job control.
- Commercial resource management software is now available that will also support GPU management but the cost is beyond our budget (the NextGen HPC uses the Torque and Maui job management systems which are open source and free of charge).
About the GPU servers
- nvidia3 is a SuperMicro GR1027GR-72R2 GPU server that can accomodate up to 3 double-width GPU cards although only two are fitted at present. Two 2.5 Ghz quad-core CPUs are fitted and 64 GB of memory is available.
- nvidia4 is a large Tyan FT77DB7109 server fitted with eight nVidia GeForce RTX 2080Ti GPUS (pictured on the left) two 16-core 2.8 GHz Xeon CPUs, 1.5 TB of memory and 14 hard disks, 2 of which are fast SAS disks arranged as a mirrored pair for the system while the other 12 form a XFS disk pool, with one disk being reserved as a 'hot spare' and having a total usable capacity of 22 TB.
- nvidia5 is an Asus ESC4000 G4 server fitted with four nVidia GeForce RTX 3090Ti GPUS, two 16-core 2.8 GHz Xeon CPUs, 256 GB of memory, two 1TB hard disks arranged as a mirrored pair for the operating system and six 1TB disks forming a XFS disk pool to provide 4.6TB of fast local storage.
- nvidia6 is an Asus ESC8000 G4 server fitted with eight nVidia GeForce RTX 3090Ti GPUS two 16-core 2.8 GHz Xeon CPUs, 896 GTB of memory, two 300 GB SAS hard disks arranged as a mirrored pair for the operating system and six 2.4TB disks to provide 11TB of local on-server data storage.