The new world of data opens the door for higher degrees of scientific simulations which enable solving problems we never thought we could solve before, and for developing advanced deep learning engines that can be utilized to improve our lives. The data center architecture has changed to support these activities, and new technologies have been developed to support the migration of the data center architecture from the old CPU-centric concept to the data-centric concept. An important part of this transition has involved the creation of new compute options, including smart and programmable interconnect solutions.
InfiniBand has long been the leading standards-based interconnect technology for high-performance computing and deep learning, and has become so now also for cloud platforms serving compute and data intensive applications. Tens of thousands of compute nodes are connected nowadays in leading cloud and hyperscale platforms, alongside many supercomputers systems around the world. The world is choosing InfiniBand as the interconnect technology that enables faster and more scalable compute and data intensive application runtimes. More InfiniBand large scale islands are being built inside traditional Ethernet infrastructures for HPC, AI, Big Data and more, and these islands are connected to Ethernet via fast gateways. Furthermore, InfiniBand is not only a leading cost-performance network, it can cost less compared to Ethernet for the same data throughput.
InfiniBand provides innovative In-Network Computing engines that reside on the network devices, which can perform arithmetic operations on network transformed data – operations such as data reductions, data matching and much more. Additionally, there are InfiniBand devices which include standard compute cores that can be easily programmed to perform other data related operations. This has positioned InfiniBand as the preferred solution versus Ethernet, or any other proprietary networks, hiding or not hiding under a “something-Ethernet” name.
Obviously this In-Network Computing innovation, where the network becomes also a “co-processor” of the data in transit, is an addition to the core mission of the data center interconnect – namely, to move data effectively and efficiently, and to ensure that the rest of the compute resources receive their data without delay. Over the years, multiple technologies and capabilities have been developed in this area, such as RDMA, GPUDirect® RDMA, Quality of Service, adaptive routing, and congestion control. While none of these technologies is foreign to standard InfiniBand, the last two basic network capabilities are new to the newest variations of proprietary networks.
Let’s take network congestion as an example. Network congestion is caused by two main reasons: point-to-point communications sharing the same network path while other paths are not being used; and many-to-one communication patterns in which the single receiver is incapable of consuming all the data coming from many senders concurrently.
Adaptive routing is the mechanism to overcome network congestion caused by the imbalanced spread of point-to-point network communications. InfiniBand adaptive routing has proven to deliver 96% network utilization, as measured using the MPIGraph benchmark by Oak Ridge National Laboratory (Source: “The Design, Deployment, and Evaluation of the CORAL Pre-Exascale Systems,” Sudharshan S. Vazhkudai, Arthur S. Bland, Al Geist, et al). InfiniBand allows fine-grain adaptive routing, and offers support for several adaptive routing schemes. As such, and based on the system design and usage, the most appropriate scheme can be used to achieve optimal performance.
The many-to-one congestion problem can be solved by congestion management or congestion control mechanisms. Key to congestion control is its reliance on the network switch to discover the many-to-one scenarios, and to trigger fast network notifications to the senders. Once a sender receives the congestion control notification, the sender reduces the amount of data it transmits to the receiver to allow for successful consumption. This way the network does not get filled with data, the switch buffers remain empty, and the many-to-one congestion scenario is avoided. Clearly, the faster the congestion notifications are issued and received, the more efficient congestion control becomes.
Back in 2010, I had the pleasure of working with the Simula laboratory team in Norway to demonstrate the InfiniBand congestion control mechanism. We built a small network with seven servers and two switches, connecting each server with a DDR 20Gb/s InfiniBand link to the switches (three servers to one switch and four servers to the second switch), and connecting the two switches with a single QDR 40Gb/s InfiniBand link. We established a case of victim flows that is caused by a many-to-one network congestion condition (victim flows are data flows that are not part of the many-to-one communication case, but suffer performance loss due to that congestion). We then demonstrated that InfiniBand congestion control both eliminates the network congestion, and prevents the development of victim flows.
Needless to say, the InfiniBand congestion control hardware mechanism has undergone multiple improvements and enhancements since 2010. For example, the latest HDR 200Gb/s InfiniBand switches and adapters support a fast detection and communication mechanism for effective and efficient congestion control.
We recently witnessed the introduction of a new network benchmark called Global Performance and Congestion Network Test (GPCNeT). This GPCNeT benchmark is an MPI level test designed to measure the impact of background traffic on random-ring latency and bandwidth, and on small-data MPI Allreduce operations. This raises the question of why has it suddenly become so important to create such a benchmark, and why not ten years ago? The main reason is that proprietary networks have had no support for congestion control until just now, and because congestion control has just been introduced in a new creation of a proprietary network.
At high level, the GPCNeT benchmark measures the three MPI operations, each separately in two scenarios: one, with part of the cluster nodes running one of MPI operation while the rest of the nodes are idle; and second, with part of the nodes running the same MPI operation while the rest of the nodes inject noise data into the fabric, creating many-to-one operations and network congestion. Then both results are compared per operation to yield a GPCNeT benchmark score.
The GPCNeT benchmark is actually a measure of relative performance under load rather than a measure of absolute performance. Therefore, GPCNeT cannot rank networks as being faster or slower than each other. With GPCNeT, a network that provides MPI Allreduce latency of 2 micro seconds without congestion and 3 micro seconds with congestion can be wrongly considered worse than a network that provides 100 micro seconds of latency without congestion and 110 micro seconds with congestion! (We all know that the lower the latency the better the network.) But this is the fault of the GPCNeT benchmark: it hides the real latency performance of a network.
Furthermore, the benchmark considers 8 bytes (for MPI Allreduce) to be the important data size, while congestion noise is based on large messages. Not to say that 8-byte MPI Allreduce is not relevant, but larger data size reductions and other collectives can have far larger impact on application performance – deep learning for one. Deep learning will become an important part of many HPC applications, and will be used to increase the accuracy of HPC simulations. Additionally, 8-byte data exchanges are indeed used, but much larger data messages (from hundreds to thousands to millions of bytes) are used much more often, and have significantly higher impact on application performance.
The above leads – and one can list many other supporting reasons – to the conclusion that GPCNeT is a very synthetic benchmark with limited benefit, and that it cannot too reliable for comparing networks in real world scenarios.
Last if we are wondering how HDR 200Gb/s InfiniBand performs under the GPCNeT benchmark, then testing results proved again HDR InfiniBand’s world-leading performance, and extremely low to no jitter. The InfiniBand congestion control mechanism was demonstrated to overcome the congestion created by the GPCNeT benchmark, and to deliver a GPCNeT congestion factor of nearly 1 – the best factor that can be achieved by this benchmark.
When it comes to evaluating high-performance computing systems or interconnects, there are much better benchmarks available for use. Moreover, the ability to benchmark real workloads is obviously a better approach for determining system or interconnect performance and capabilities. The drawbacks of GPCNeT benchmarks can be much more than its benefits. GPCNoT?