HPC Performance Benchmarking

High-Performance Computing (HPC) benchmarking is a critical process for evaluating the performance, efficiency, and capabilities of supercomputers and computing clusters. This process involves running a series of standardized tests and workloads that simulate real-world computational tasks. These benchmarks help determine how effectively an HPC system can handle complex, resource-intensive applications such as scientific simulations, data analysis, and machine learning.

Key aspects of HPC benchmarking include evaluating the system’s computational speed, memory bandwidth, storage performance, and network latency. Common benchmarks include LINPACK, which measures a system’s ability to solve linear equations, and the OSU Micro-Benchmarks (OMB), which assess a wide range of MPI-based workloads distributed across multiple nodes within a cluster. By performing these benchmarks, organizations can make informed decisions about system upgrades, compare different HPC systems, identify bottlenecks, and optimize computational resources for enhanced performance and efficiency.

At the University of Surrey we have conducted a number of different types of benchmarking exercises for our HPC clusters and associated data storage systems. We have included some information on some of those benchmarking techniques below.

Benchmarking with LINPACK

This benchmark evaluates the cluster’s capability to process floating-point operations, measured in gigaflops (Gflops) per second, using a single node. We have carried out these tests on three of our clusters: AISurrey, Eureka2, and Kara2.

An interactive session is started on one of the compute nodes and then the LINPACK test suite is executed.

These tests assess the hardware capabilities (CPU and RAM) for solving numerical equations and measure processing performance. Consistent test configurations are used across all clusters, and the average and maximum performances in Gflops are recorded.

Test Configuration Parameters:

• Number of tests: 1

• Number of equations to solve (problem size) : 16

• Leading dimension of array : 20000

• Number of trials to run : 1000

• Data alignment value (in Kbytes) : 4

Sample outputs (from 1000 trials):

=================== Timing linear equation system solver ==========================

Size	LDA	Align.	Time(s)	GFlops	Residual	Residual(norm)	Check
16	20000	4	0.007	0.0004	9.436896e-16	1.095092e-01	pass
16	20000	4	0.000	0.1707	9.436896e-16	1.095092e-01	pass
16	20000	4	0.000	0.1876	9.436896e-16	1.095092e-01	pass
16	20000	4	0.000	0.2002	9.436896e-16	1.095092e-01	pass

AISURREYEureka2Kara02

• CPU frequency: 2.999 GHz

• Number of CPUs: 2

• Number of cores: 64

• Number of threads: 64

Performance Summary (GFlops)

Size	LDA	Align.	Average	Maximal
16	20000	4	0.8864	0.9856

Benchmarking parallel computing with OSU Micro-Benchmarks

The OSU Micro-Benchmarks focus on evaluating network performance between nodes. We currently perform two types of tests based on the OpenMPI suit:

Note

OSU Micro-benchmarks are not applied to AISurrey because it does not support multi-node distributed execution, such as MPI or OpenMPI. The nodes are standalone and not interconnected, unlike those in Eureka2 and Kara2.

Bandwidth Test

In this test, the sender transmits a predetermined number of back-to-back messages (matching the window size) to the receiver, then waits for a response. The receiver only sends a reply after receiving all the messages. This process is repeated over several iterations, and the bandwidth is calculated based on the time taken (from when the first message is sent until the reply is received) and the total number of bytes transmitted by the sender.

The goal is to measure the maximum sustained data transfer rate at the network level. Non-blocking MPI functions (MPI_Isend and MPI_Irecv) are used.

Network Bandwidth - Eureka2 vs. Kara2

Screenshot: Network Bandwidth Graph - Eureka2 vs. Kara2

Latency Test

This test is conducted using a ping-pong message exchange between two nodes in the cluster. The sender transmits a message of a certain data size to the receiver, which then sends a reply with the same data size back to the sender. This exchange is repeated over many iterations, and the average one-way latency is measured. Blocking MPI functions (MPI_Send and MPI_Recv) are used.

Network Latency - Eureka2 vs. Kara2

Screenshot: Network Latency Graph - Eureka2 vs. Kara2

BeeGFS Filesystem performance benchmarks

We have also benchmarked the performance of the Parallel scratch storage system on Eureka2. See BeeGFS parallel scratch storage for more details.