| Feature | Login Nodes | Transfer Nodes | Development Nodes | Compute Nodes |
|---|---|---|---|---|
| SSH access from outside of cluster | Within UCSF only, incl. UCSF VPN | Within UCSF only, incl. UCSF VPN | no | no |
| SSH access from inside of cluster | ✓ | ✓ | ✓ | no |
| Outbound access | No restrictions | HTTP/HTTPS, FTP/FTPS, SSH, SFTP, GIT+SSH, Globus | No restrictions | no |
| Network speed | 1 Gbps | 10 Gbps | 1 Gbps | 1,10 Gbps |
| Core software | Minimal | Minimal | Rocky packages, compilers and source-code packages | Same as development nodes |
| modules (software stacks) | Limited subset | Limited subset | ✓ | ✓ |
| Global file system | ✓ | ✓ | ✓ | ✓ |
| Job submission | ✓ | no | ✓ | ✓ |
| Purpose | Submit and query jobs. SSH to development nodes. File management. | Fast in- & outbound file transfers. File management. | Compile and install software. Prototype and test job scripts. Submit and query jobs. Version control (clone, pull, push). File management. | Running short and long-running job scripts. |
All nodes on the cluster runs Rocky 8 which is updated on a regular basis. The job scheduler is Slurm 21.08 (Simple Linux Utility for Resource Management) which provides partitions for both communal and lab-priority tasks.
The cluster can be accessed via SSH to one of two login nodes:
c4-log1.ucsf.educ4-log2.ucsf.eduFor transferring large data files, it is recommended to use one of the dedicate data transfer nodes:
c4-dt1.ucsf.educ4-dt2.ucsf.eduwhich have 10 Gbps connection - providing a file transfer speed of up to (theoretical) 1.25 GB/s = 4.5 TB/h. Please note, as is true for all ethernet, 80% of line speed is doing pretty good. As for the login nodes, the transfer nodes can be accessed via SSH.
Comment: You can also transfer data via the login nodes, but since those only have 1 Gbps connections, you will see much lower transfer rates.
The cluster has development nodes for the purpose of validating scripts, prototyping pipelines, compiling software, and more. Development nodes can be accessed from the login nodes.
| Node | Logical Cores | RAM | Local /scratch |
CPU x86-64 level | CPU | GPU |
|---|---|---|---|---|---|---|
| c4-dev2 | 48 | 512 GiB | 1.1 TiB | x86-64-v1 | AMD Opteron Processor 6176 | |
| c4-dev3 | 38 | 128 GiB | 5.4 TiB | x86-64-v3 | Intel Xeon E5-2640 v4 2.40GHz | |
| c4-gpudev1 | 104 | 1024 GiB | 3.4 TiB | x86-64-v4 | Intel Xeon Gold 5320 2.20GHz | Nvidia A40 GPU |
Comment: Please use the GPU development node only if you need to build or prototype GPU software. The CPU x86-64 level is the x86-64 microarchitecture levels supported by the nodes CPU.
The majority of the compute nodes have Intel processors, while a few have AMD processes. Each compute node has a local /scratch drive (see below for size), which is either a hard disk drive (HDD), a solid state drive (SSD), or a Non-Volatile Memory Express (NVMe) drive. Each node has a tiny /tmp drive (8-8 GiB).
| Node | Logical Cores | RAM | Local /scratch/ |
CPU x86-64 level | CPU | Notes | Priority |
|---|---|---|---|---|---|---|---|
| c4-n1 | 64 | 512 GiB | 1.8 TiB | x86-64-v4 | 2.1 GHz | SSD /scratch, 10 Gbps ethernet | communal |
| c4-n2 | 64 | 512 GiB | 1.8 TiB | x86-64-v4 | 2.1 GHz | SSD /scratch, 10 Gbps ethernet | communal |
| c4-n3 | 64 | 512 GiB | 1.8 TiB | x86-64-v4 | 2.1 GHz | SSD /scratch, 10 Gbps ethernet | communal |
| c4-n4 | 64 | 512 GiB | 1.8 TiB | x86-64-v4 | 2.1 GHz | SSD /scratch, 10 Gbps ethernet | communal |
| c4-n5 | 64 | 512 GiB | 2.6 TiB | x86-64-v4 | 2.1 GHz | SSD /scratch, 10 Gbps ethernet | communal |
| c4-n6 | 112 | 768 GiB | 11.0 TiB | x86-64-v4 | 2.2 GHz | NVMe /scratch, 10 Gbps ethernet | Witte Lab |
| c4-n7 | 112 | 768 GiB | 11.0 TiB | x86-64-v4 | 2.2 GHz | NVMe /scratch, 10 Gbps ethernet | Witte Lab |
| c4-n8 | 112 | 768 GiB | 11.0 TiB | x86-64-v4 | 2.2 GHz | NVMe /scratch, 10 Gbps ethernet | Witte Lab |
| c4-n9 | 112 | 768 GiB | 11.0 TiB | x86-64-v4 | 2.2 GHz | NVMe /scratch, 10 Gbps ethernet | Witte Lab |
| c4-n10 | 48 | 512 GiB | 2.3 TiB | x86-64-v2 | 2.1 GHz | SATA /scratch, 10 Gbps ethernet | communal |
| c4-n11 | 128 | 1024 GiB | 5.2 TiB | x86-64-v4 | 2.8 GHz | SSD /scratch, 10 Gbps ethernet | Costello Lab |
| c4-n12 | 64 | 512 GiB | 3.6 TiB | x86-64-v2 | 2.6 GHz | SATA /scratch, 10 Gbps ethernet | CBI Core |
| c4-n13 | 64 | 512 GiB | 3.6 TiB | x86-64-v2 | 2.6 GHz | SATA /scratch, 10 Gbps ethernet | CBI Core |
| c4-n14 | 24 | 128 GiB | 0.9 TiB | x86-64-v2 | 3.5 GHz | SATA /scratch, 10 Gbps ethernet | Witte Lab |
| c4-n15 | 64 | 256 GiB | 1.8 TiB | x86-64-v2 | 2.6 GHz | SATA /scratch, 10 Gbps ethernet | Witte Lab |
| c4-n16 | 64 | 512 GiB | 3.3 TiB | x86-64-v4 | 3.7 GHz | SATA /scratch, 10 Gbps ethernet | Blelloch Lab |
| c4-n17 | 64 | 512 GiB | 2.6 TiB | x86-64-v4 | 3.7 GHz | SAS /scratch, 10 Gbps ethernet | Francis Lab |
| c4-n18 | 64 | 512 GiB | 3.2 TiB | x86-64-v3 | 2.1 GHz | SAS /scratch, 10 Gbps ethernet | Krummel Lab |
| c4-n19 | 64 | 768 GiB | 4.9 TiB | x86-64-v4 | 3.7 GHz | SAS /scratch, 10 Gbps ethernet | Ziv Lab |
| c4-n20 | 48 | 384 GiB | 7.0 TiB | x86-64-v3 | 2.4 GHz | SATA /scratch, 10 Gbps ethernet | Krummel Lab |
| c4-n21 | 64 | 512 GiB | 11.0 TiB | x86-64-v3 | 2.6 GHz | SAS /scratch, 10 Gbps ethernet | Witte Lab |
| c4-n22 | 128 | 512 GiB | 2.6 TiB | x86-64-v4 | 3.7 GHz | SSD /scratch, 10 Gbps ethernet | Kim Lab |
| c4-n23 | 64 | 512 GiB | 2.7 TiB | x86-64-v3 | 2.3 GHz | SSD /scratch, 10 Gbps ethernet | Shannon Lab |
| c4-n24 | 64 | 512 GiB | 2.6 TiB | x86-64-v4 | 3.7 GHz | SSD /scratch, 10 Gbps ethernet | Shannon Lab |
| c4-n25 | 64 | 512 GiB | 2.6 TiB | x86-64-v4 | 3.7 GHz | SSD /scratch, 10 Gbps ethernet | Bastian Lab |
| c4-n27 | 64 | 512 GiB | 3.2 TiB | x86-64-v4 | 2.1 GHz | SAS /scratch, 10 Gbps ethernet | Kriegstein Lab |
| c4-n28 | 48 | 384 GiB | 5.4 TiB | x86-64-v3 | 2.8 GHz | SATA /scratch, 10 Gbps ethernet | Molinaro Lab |
| c4-n29 | 48 | 384 GiB | 5.4 TiB | x86-64-v3 | 2.8 GHz | SATA /scratch, 10 Gbps ethernet | Molinaro Lab |
| c4-n30 | 32 | 192 GiB | 0.05 TiB | x86-64-v3 | 1.2 GHz | SAS /scratch, 2x1 Gbps ethernet | Oldham Lab |
| c4-n31 | 64 | 512 GiB | 3.2 TiB | x86-64-v4 | 2.1 GHz | SAS /scratch, 10 Gbps ethernet | Diaz Lab |
| c4-n32 | 64 | 512 GiB | 5.4 TiB | x86-64-v3 | 2.6 GHz | SATA /scratch, 10 Gbps ethernet | Costello Lab, Diaz Lab, Fung Lab |
| c4-n33 | 64 | 512 GiB | 5.4 TiB | x86-64-v3 | 2.6 GHz | SATA /scratch, 10 Gbps ethernet | Costello Lab, Diaz Lab, Fung Lab |
| c4-n34 | 64 | 512 GiB | 5.4 TiB | x86-64-v3 | 2.6 GHz | SATA /scratch, 10 Gbps ethernet | Costello Lab, Diaz Lab, Fung Lab |
| c4-n35 | 64 | 512 GiB | 2.6 TiB | x86-64-v4 | 2.1 GHz | SSD /scratch, 10 Gbps ethernet | Krummel Lab |
| c4-n36 | 48 | 384 GiB | 5.4 TiB | x86-64-v3 | 1.4 GHz | SATA /scratch, 10 Gbps ethernet | Costello Lab |
| c4-n37 | 104 | 1024 GiB | 3.4 TiB | x86-64-v4 | 3.4 GHz | SSD /scratch, 10 Gbps ethernet | communal |
| c4-n38 | 104 | 1024 GiB | 3.4 TiB | x86-64-v4 | 3.4 GHz | SSD /scratch, 10 Gbps ethernet Nvidia A100 GPU | communal |
| c4-n39 | 104 | 1024 GiB | 3.4 TiB | x86-64-v4 | 3.4 GHz | SSD /scratch, 10 Gbps ethernet Nvidia A100 GPU | communal |
| c4-n40 | 160 | 1024 GiB | 3.5 TiB | x86-64-v4 | 2.3 GHz | SATA /scratch, 10 Gbps ethernet | Krummel Lab |
| c4-n41 | 128 | 1024 GiB | 5.2 TiB | x86-64-v4 | 2.0 GHz | SATA /scratch, 10 Gbps ethernet | Krummel Lab |
| c4-n42 | 160 | 768 GiB | 5.4 TiB | x86-64-v4 | 2.3 GHz | SATA /scratch, 10 Gbps ethernet | Vantveer Lab |
| c4-n43 | 256 | 1024 GiB | 30 TiB | AMD EPYC 9554 | 3.1 GHz | SSD /scratch, 10 Gbps ethernet | Sweet-Cordero Lab |
The compute nodes can only be utilized by submitting jobs via the scheduler.
c4-n38 and c4-n39 #
The servers c4-n38 and c4-n39 each contain a single NVIDIA A100 80GB PCIe GPU.
Each GPU is currently configured into seven MIG (Multi-Instance GPU) devices, each providing roughly 10 GB of GPU memory.
This configuration allows multiple GPU jobs to run concurrently on the same GPU, improving utilization and keeping workloads isolated from one another.
MIG, or Multi-Instance GPU, is a feature of NVIDIA’s A100 architecture.
It allows a single GPU to be divided into multiple isolated GPU “instances.”
Each instance behaves like an independent GPU with its own:
As a result, multiple users or jobs can safely share one GPU without interfering with each other.
Each A100 80 GB GPU is split into 7 × 1g.10gb instances:
Better Utilization
Without MIG, only a single process can occupy the GPU—even if it uses a small portion of its capacity.
With MIG, up to seven smaller jobs can run at once, keeping the GPU busy.
Isolation
Each MIG device is hardware-isolated.
A crash or memory overflow in one instance does not affect others.
Good Fit for Current Workloads
Most research and inference tasks use less than 10 GB of GPU memory, so this layout allows multiple experiments to run simultaneously.
Flexibility
The configuration can be changed if a project requires a larger GPU slice.
You can request the full 80 GB GPU from the system administrator if needed.
Run:
$ nvidia-smi
Thu Oct 16 07:14:58 2025
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 560.35.03 Driver Version: 560.35.03 CUDA Version: 12.6 |
|-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA A100 80GB PCIe On | 00000000:CA:00.0 Off | On |
| N/A 67C P0 183W / 300W | 45269MiB / 81920MiB | N/A Default |
| | | Enabled |
+-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+
| MIG devices: |
+------------------+----------------------------------+-----------+-----------------------+
| GPU GI CI MIG | Memory-Usage | Vol| Shared |
| ID ID Dev | BAR1-Usage | SM Unc| CE ENC DEC OFA JPG |
| | | ECC| |
|==================+==================================+===========+=======================|
| 0 7 0 0 | 13MiB / 9728MiB | 14 0 | 1 0 0 0 0 |
| | 0MiB / 16383MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 0 8 0 1 | 7548MiB / 9728MiB | 14 0 | 1 0 0 0 0 |
| | 2MiB / 16383MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 0 9 0 2 | 7548MiB / 9728MiB | 14 0 | 1 0 0 0 0 |
| | 2MiB / 16383MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 0 11 0 3 | 7540MiB / 9728MiB | 14 0 | 1 0 0 0 0 |
| | 2MiB / 16383MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 0 12 0 4 | 7540MiB / 9728MiB | 14 0 | 1 0 0 0 0 |
| | 2MiB / 16383MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 0 13 0 5 | 7540MiB / 9728MiB | 14 0 | 1 0 0 0 0 |
| | 2MiB / 16383MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
| 0 14 0 6 | 7540MiB / 9728MiB | 14 0 | 1 0 0 0 0 |
| | 2MiB / 16383MiB | | |
+------------------+----------------------------------+-----------+-----------------------+
+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| 0 8 0 3479490 C python 7528MiB |
| 0 9 0 3479493 C python 7528MiB |
| 0 11 0 3479524 C python 7520MiB |
| 0 12 0 3479535 C python 7520MiB |
| 0 13 0 3479546 C python 7520MiB |
| 0 14 0 3479557 C python 7520MiB |
+-----------------------------------------------------------------------------------------+
The C4 cluster provides two types of scratch storage:
/scratch/ - 0.05-11 TiB/node storage unique to each compute node (can only be accessed from the specific compute node)./c4/scratch/ - 240 TiB storage accessible from everywhere.There are no per-user quotas in these scratch spaces. Files not added or modified during the last two weeks will be automatically deleted on a nightly basis. Note, files with old timestamps that were “added” to the scratch place during this period will not be deleted, which covers the use case where files with old timestamps are extracted from tar.gz file. (Details: tmpwatch --ctime --dirmtime --all --force is used for the cleanup.)
/c4/home: 196 TiB storage spaceEach user may use up to 1 TiB disk space in the home directory. It is not possible to expand user’s home directory. Many labs have purchased their own storage servers which were then mounted on the cluster. If you’d like more information please contact Adam Olshen or Harry Putnam.
⚠️ Importantly, note that, aside from /c4/home, the C4 storage is not backed up. Users and labs are responsible to back up their own data outside of C4.
The compute nodes are connected to the local network with 1 Gbps and 10 Gbps network cards.