Ampere Altra Wiwynn Mt. Jade Server Topology
We wanted to show this briefly since we often have topology maps. Like Intel Xeon Scalable systems with SNC, and AMD systems with NPS, we can split the otherwise large number of cores into subsets more locally attached to DDR4 memory controllers. Even though the Ampere Altra Q80-33 is a single monolithic die design, with 80 cores we can present the topology effectively as four NUMA nodes per CPU, each with 20 cores. It was not long ago that a 20 core CPU was a large chip in the Xeon E5 era.
That topology map is completely unreadable simply due to having 160 cores being presented. You can click on it to get to larger versions if you are interested.
Next, we are going to look at our test configuration.
The base test configuration we are using consists of:
- System: Wiwynn Mt. Jade Server
- CPUs: 2x Ampere Altra Q80-33 80 core/ 3.3GHz CPUs
- Memory: 16x 32GB DDR4-3200 ECC RDIMMs (Samsung)
- Networking: 1x NVIDIA ConnectX-6 200GbE adapter, 1x NVIDIA ConnectX-5 2x 100GbE adapter
- Storage: 1x Samsung boot NVMe SSD, 2x Kioxia CD6-L (1.92TB and 7.68TB), 1x Kioxia CM6 6.4TB, 1x Samsung 983T 960GB, 1x Samsung PM1733a 3.84TB SSD
- GPU: 1x NVIDIA T4
We added a few components to the base configuration since we wanted to see how the system responded to adding new components. Overall, the process went well. This is a great point of evolution since the original ThunderX(1) days in 2016 when adding a component often meant a challenging bring-up process.
Wiwynn Mt. Jade Server Management
In terms of management, we get a fairly standard MegaRAC SP-X management interface. There are Redfish management APIs in this solution as well, but we want to focus on the management interface.
There are little items here that we wanted to show off. The first may seem small, but most of the FRU information is filled out even though this is a pre-production system. This may seem like a small detail, but at STH we often get systems with SP-X interfaces that do not have this information, especially on pre-production systems. Wiwynn produces high quantity/ quality servers, so there are little touches like this that stand out.
Something that is welcome on an Arm server platform is a HTML5 iKVM solution with remote media mounting. We have had iKVMs on previous systems, usually Java-based, and often less reliable in their operation. This worked as we would expect on an x86 server. While that may not seem notable, for an Arm server, it is.
We also get a standard web firmware update feature found in x86 servers. In previous generations, this often required a more advanced procedure with written steps, a CLI and a serial connection “just in case.” Now, we have an x86-like interface to update firmware even through the web GUI.
We quickly spot-checked the rest of the SP-X interface, and this seemed about what we would expect from a base-level implementation. We did not see major added features from Wiwynn here.
At the same time, there is something to be said for the fact that this simply worked. After having lived with Arm servers for over 4-5 years, this is an enormous accomplishment by the Wiwynn and Ampere teams. It is also something that needed to happen in order for these servers to go more mainstream and start displacing x86 sockets outside of just hyper-scalers so this is a seemingly small, but an impactful aspect of the solution.
With the hardware and management covered, it is now time to look at performance.