Los Alamos Lead Shares “Trinity” Feeds and Speeds
We’ve been anticipating news around the Trinity supercomputer for some time now and today were graced with the news that Cray will be supplying the machine in two phases with the final phase being complete in 2016. For the original background, the first run of the story can be found here.
Since that time this morning, we were able to have an in-depth discussion with one of the key thinkers at the heart of the procurement, Los Alamos National Labs’ HPC division leader, Gary Grider. His foundational work on burst buffers (a term he coined) features prominently in the other half of the procurement, the NERSC “Cori” system, but he’s also been instrumental in making system-level choices for the NNSA’s mission-critical Trinity supercomputer, along with a great deal of assistance from project partners at Sandia.
Grider told us the team at Los Alamos is already busy installing the extra power and cooling needed to ready space inside the existing Strategic Computing Complex at the lab with the 45,000 square feet of space for the new system. The approximately 270 next-generation Cray XC racks won’t occupy that entire space, says Grider, but the 10,000 square feet it needs will be prepared with the warm water cooling infrastructure needed to keep the Haswell and Knight’s Landing-based nodes cool, while feeding recycled water that isn’t in the racks out into protected wetlands—thus offsetting some of the concerns about the 8-10 MW that the new super will likely consume. In the bigger picture, however, Los Alamos is thinking ahead—the facility itself is preparing to handle far more in terms of power and cooling with the capability of 30 MW in sight.
We weren’t able to tell this morning how large the machine might be, but started piecing things together with some information that’s available. We know that the next-generation Haswell core count will fall somewhere in the 14-18 range (perhaps up to 24—we’ll find this out in upcoming Intel announcements, probably this quarter) and with the additional Knight’s Landing chips, which will sport on-package memory and anywhere between 60-72 cores, according to the data we have available. In the end, Grider confirmed that the system will (like way far) exceed the original performance targets of 30 petaflops, but he’s not sure how far over the mark it will go for the machine. There’s some speculative math coming your way soon on this…but even if half the machine is just the Xeon…whew.
As we noted earlier today, we’ll do the math once the most recent Haswell core counts and expected performance/thermals come out soon—and add it to whatever Intel cares to share later this year about the future performance of its self-hosted Knight’s Landing part.
For those who keep supercomputing score (and Grider isn’t one of them—he doesn’t care about the FLOPS, he cares about getting 6x-8x the performance of their workhouse “Cielo” machine) recall that this would put the 2015-2016 NNSA supercomputer just around the existing #1 system in the world for 2 years running—China’s Tianhe-2. No small feat, but Grider says that they’re not planning LINPACK unless the vendors ask them to. And if Cray thought that spike in their stock price was attractive today, having twice a year news around another top super couldn’t hurt.
The two phases of the project mean that the first cores that will hit the floor will be the Haswells because the facility cannot wait for the Knight’s Landing to come into play. He says that for the other side of the procurement at NERSC, they had more flexibility in waiting on the chips because they have enough capacity to keep the Office of Science machines and researchers fed. The problem at the NNSA, however, is that they need more computing power immediately. They’re going to complete an install of the first set of Haswell-based machines in the summer of 2015—but the delay is just facilities-related. They need to get their power and cooling infrastructure secured before these can go in, he said, stressing that there are no delays on Intel’s part expected for the first component.
The precise configuration of the nodes in the Trinity machine have not been divulged, but it looks like there will be compute nodes with multiple Haswell Xeon E5 v3 processors on them as well as compute nodes that have multiple Knights Landing Xeon Phi processors on them. All of these devices will be connected using the Aries XC interconnect in its dragonfly topology.
It is not clear exactly how the processors will link to the Aries interconnect, but the current Aries chip is a 48-port router that has four PCI-Express 3.0 lanes linking to four two-socket Xeon nodes. The Aries chip also has three different ranks of connectivity: Rank 1 goes into the backplane, Rank 2 is a copper network for linking six XC enclosures to each other, and Rank 3 is an optical network that links multiple rack pairs to each other. Each server node has four two-socket servers and Aries interconnect in the current design. Conceptually, you could put Xeon E5s and Xeon Phis on the same server form factor. The important thing is that the Aries interconnect allows all nodes in the system to talk to one another. The system has what Cray calls adaptive routing, making use of multiple routes in the network to get around congestion, and that implies that the system can start out with Xeon processors and have Xeon Phi chips added later with relative ease.
One little note about the architectural choice goes back to an actual lack of choice. Grider says he’s been watching OpenPower efforts carefully, but they’re mission-driven at the NNSA and need the power and bandwidth now. The OpenPower roadmap, while presenting some attractive features, was too long to consider.
Discrete GPUs were not an option for the same reasons, said Grider, noting, “we probably would have considered this as an option if there was a self-hosted GPU of some kind or higher bandwidth than a PCI bus. Again, if you look at the time we were making these decisions and the chips avail in the timeframe, you’ll see that there’s really nothing else out there right now.”
While the architectural choice is already being questioned by some as being more conservative than expected, there are a few things to keep in mind. Unlike open science centers (including NERSC) the application demands are limited in terms of scope. Grider says there are less than a dozen codes set to run on the monster, but these have been refined and blessed over the course of many years. We don’t mess around when it comes to our nuclear facilities. This means retooling codes to fit into architectural boxes is impractical and further, that they have a very defined sense of exactly what they need. The choices for architecture, while very conservative, were the only choices.
But it’s not like there’s nothing interesting happening here. For instance, Grider, the originator of the burst buffer term and early research, said that they’re going to be seeking as much performance out of their flash array as possible—using the burst buffer technology for the first time on a large-scale machine in 2015 to see how it adds to their reliability and 90% utilization goals. And from a memory perspective, it’s nothing to sneeze at either—with 2-3 petabytes of main memory, that 7 petabyte flash gear to support the burst buffer, and 82 petabytes of disk, it’s quite the powerhouse overall—and even conservative for a burst buffer until they see exactly how Cray’s Tiered Storage stuff works in action.
“The burst buffer might be in the 5-7 TB/sec and the disk system is 1-2 TB/sec. The models show that you could sustain the 90% goal with less disk bandwidth, more like 10x less than the burst buffer BW instead of the 4-5x on this machine. This was a deliberate choice because of the immaturity of the burst buffer solution space. This is the first burst buffer solution being deployed and it is a pretty large scale deployment as well, so there is reason to be a little conservative. If we had complete confidence in the burst buffer solutions at this scale, we could have saved money by buying less disk BW. Future machines can be more aggressive in this area,” said Grider.
But there are risks, even with a conservative architecture. When asked what he worries about most in terms of implementation and early use nitty-gritty, Grider said there is concern that the architecture takes a turn from the heterogeneous approach where they had a strong integer machine and a strong processor (as with Roadrunner’s AMDs) where the network was attached. “Since Knights Landing is such a flat architecture, where it’s just a bunch of equivalent-sized processors that are smaller and weaker whereas for hot processes you want a stronger processor, we’re going to have to do some thinking,” he said. In the next month, Grider added they’ll be pulling in more long-term support from Intel and hotboxing their codes in early Knights Landing machines to navigate these worries.
Our congrats to Cray and the NNSA–this will be a great story to watch unfold….