Last year following the launch of the Intel Xeon 6900P Granite Rapids processors I ran some benchmarks looking at the SNC3 vs. HEX clustering mode performance. With having an Intel Xeon 6980P server back up and running on a Giga Computing R284-A92-AAL server after my AvenueCity reference server failed nearly one year ago, I revisited the SNC3 vs. HEX clustering performance for those curious how it’s looking on a modern software stack and with new/updated benchmarks.
SNC3 sub-NUMA clustering is the default mode of operation for Xeon 6900P processors where each compute die is exposed as its own NUMA domain. With Granite Rapids’ new “HEX” mode, it’s like the mode formerly known as SNC1 where there is a single NUMA domain for each processor on the server. With the HEX mode for the single NUMA domain per processor it can perform better for software not adapted to properly leverage multiple NUMA domains but can run into L3 cache and memory latency penalties for other workloads.
Ultimately the SNC3 vs. HEX sun-NUMA clustering mode depends upon what workload(s) are most important to you on Intel Xeon 6 servers and the option can be easily toggled from the BIOS.
Confirming the sub-NUMA clustering mode can be confirmed via the “lscpu” output for the different NUMA domains. For this fresh round of SNC3 vs. HEX benchmarking the two Intel Xeon 6980P processors were running on the Giga Computing R284-A92-AAL server. Thanks again to Giga Computing (Gigabyte) for providing this 2U Xeon 6900P server platform for long-term testing at Phoronix to make this fresh Granite Rapids Linux benchmarking possible at Phoronix.
The two Xeon 6980P processors were each running with 12 x 64GB MRDIMM-8800 memory, Kioxia PCIe 5.0 NVMe SSD, and running Ubuntu 25.10 with the Linux 6.18 development kernel for a very leading-edge software stack. From there dozens of different benchmarks were carried out in the SNC3 and HEX modes for reference purposes for those curious about the impact of changing the sub-NUMA clustering mode on Granite Rapids.
