HPCwire recently sat down with Moray McLaren, research and development manager at Quadrics Ltd., a leading supplier and developer of high performance networking products and resource management software. The company's applied advanced technology builds clusters that deliver supercomputing levels of performance and reliability. Its QsNet products are based on internally developed ASICs, firmware and software technologies. With a fine track record of working in partnership with other HPC companies as well as organizations such as Lawrence Livermore and Los Alamos National Laboratories, the Pittsburgh Supercomputer Center and Pacific Northwest National Laboratory, Quadrics is at the forefront of helping solve some of the world's most complex computational challenges.

HPCwire: Interconnect vendors such as Quadrics make a lot of their low message latency these days, but how far is this really a measure of capability of an interconnect?

McLaren: Simple latency measurements can give an indication of the potential of an interconnect, but you need to be careful that they are measured in the way that the interconnect will actually be used in the final system. For example, latency is typically measured across just a pair nodes, but when the final system scales up to thousands [of nodes], then you need to consider scaling in both the hardware and software. It's fairly obvious the worst-case hardware latency across a larger network will be higher as you have to traverse more switches, but in some cases the software latencies are higher too since they have to employ different buffer structures for larger scale networks. At Quadrics, we use the same software across all sizes of network. We have ultra low hop latency in our switch so as to reduce the hardware scaling factor

HPCwire: So does the choice of MPI stack effect the measured latency?

McLaren: Surprisingly, not as much as you would think. At Quadrics, we support the Scali, Intel and HP multi-platform MPIs. The simple end-to-end latency is similar across all of them. The Scali and Intel implementations map onto the DAPL abstraction layer. Since the basic transfer mechanism is a remote write operation, which maps very closely onto the mechanisms of the base hardware, there's little overhead here. The problem with MPI implementations that are based on simple puts is that they required order(N) buffer space. This is acceptable for systems of a few hundreds of nodes, but on a 1,000-way network, this can be a significant fraction of the node memory. The way around this is to use a common queue, with the network interface allocating the buffer space. This requires more intelligence on the network interface and can add to latency.

HPCwire: How would you expect it to vary with node architecture?

McLaren: The devil is in the detail here. The actual CPU architecture choice -- and even to some extent, the bus choice -- are not as important as how "close" the IO bus is to the main memory. In common with most vendors, our current best case latencies are measured on the Opteron platform. But this is as much factor of the integration of the Opteron memory system, as to Hypertransport. In fact, our standard QsNet II adapters produce similar low latencies to other NICs developed specifically for Hypertransport. Newer Intel platforms that bring the PCI- Express interface closer to the memory system are starting to close the gap

When you start looking at larger NUMA systems, then it becomes much more complex, since the latency varies depending on which CPU group you are in and the location on the source and destination memory buffer. At Quadrics, we support multiple rails of interconnect. In this case, the software automatically allocates the communication to the lowest latency adapter.

HPCwire: Would using other APIs give deliver a lower latency result?

McLaren: The Cray Shmem message layer is a simple "put get" mechanism and as such maps well onto any interconnect based on put-and-get. The other key advantage is there is no unnecessary sequentialization of messages. In Shmem, there is effectively a relaxed store order model, which gives the hardware the maximum opportunity to handle communications in parallel. For this reason, it's also a good fit for multi-threaded applications that need to communicate.

HPCwire: Quadrics makes a big deal about collectives performance. Why is this important?

McLaren: If you have a code that has been structured to make extensive use of collective operations, then by having a high performance, highly scalable collective implementation, you can insure that the code will scale well to large numbers of nodes. In our collectives implementation, we actually do the double precision floating point operations on the processor embedded in the network interface. This saves the delays of passing results back and forth across the IO bus to the main processor.

HPCwire: Then aren't bandwidth measures much more straightforward?

McLaren: Since bandwidth is measured over large messages, it is typically less sensitive to software issues. However, you need to watch for people quoting throughput bandwidth, for where a number of simultaneous transfers are used to saturate the link, compared to the bandwidth for a single message transfer. As the message length becomes very large, you can start to run into limitations with the size of mapping hardware or with lock down caches. On Quadrics NICs, we implement a full Memory Management Unit capable of mirroring the main processors VM mappings to avoid this limitation.

HPCwire: So given the limitations of simple benchmarks, wouldn't it be better to test everything with the final applications?

McLaren: For limited size systems, this is indeed preferable, but for the very largest systems this just isn't practical. The good thing about the more straightforward communications benchmarks is that, for a well designed interconnect, the scaling performance is usually very predictable. When you run a complex application, then Amdahl's law means that predicting the performance is much more complex. However, at least if you start with an platforms designed from the outset for scalability, the programmer can concentrate on any potential issues within the code, without being concerned that a performance problem is an artefact of the underlying hardware.