A Tutorial of the RDMA Model

By Renato Recio

September 15, 2006

[Editor's note: The complete article with graphics is available at http://www.hpcwire.com/hpc/885757.html]

RDMA encompasses more than can be encapsulated by a reference to RDMA Writes and RDMA Reads. The reduction of the RDMA programming model by describing a poor mapping over MPI or for that matter Sockets indicates a limited understanding of the extensive capabilities of the full RDMA Model.

Forward thinking architects look to future trends instead of stretching to illustrate (or alluding to) similes with past implementations when gauging the value of a technology. This paper will show how current trends in basic and derivative technologies, such as the periodic doubling of CMOS density, will continue to cement RDMA's already significant traction with HPC, its deep incorporation into the OS, and its growing position in database and storage solutions.

This article begins with an overview of the RDMA Model and then describes the attributes of a well performing RDMA chip architecture. It will describe how the RDMA Model can benefit existing APIs, such as MPI and Sockets. At the dismay of legacy network adapter architectures, it is worthwhile to note that APIs also evolve to take advantage of standardized networking enhancements. This article will describe API evolutionary steps that enable even higher performance benefits.

RDMA Model Basics

The RDMA Model is more than RDMA Writes and RDMA Reads. The RDMA Model provides mechanisms that enable out of user space operations to a previously registered user space memory buffer without operating system (OS) involvement. The registrations are stored in memory translation and protection tables (MTPT), which can be stored in system or adapter memory. These registrations are then used to translate and validate data that is being transmitted from or placed into the registered buffer. The data transfer mechanisms include Sends, RDMA Writes, RDMA Reads and Atomics, some vendors may have proprietary value added mechanisms too.

The RDMA Model is more than RDMA Writes and Reads. Following are the major capabilities that define the RDMA Model and contribute to making it the highly efficient solution that it is:

* The support of many Send/Receive Work Queue (WQ) Pairs (QPs), in the order of thousands to millions.

* Memory registration of user space buffers with the adapter and a mechanism to associate a registered buffer with one or more QPs.

* QP Work Queue Elements (WQEs) that can reference any previously registered buffers.

* Several standard Send WQE operation types: Send, RDMA Write and RDMA Read. In the case of InfiniBand these also include Atomic Fetch & Add and Compare & Swap.

* A mechanism to signal and retrieve the completion results of a previously submitted WQ operation.

To support the full range of middleware targeted by RDMA, a good RDMA Model ASIC has the following characteristics:

* It fully offloads the transport and data placement mechanisms. For example, having to wake up a thread to process an RDMA Write is a bad implementation that does not support all the middleware the RDMA Model targets.

* Transport and data placement performed via parallel finite state machines (FSMs). When a given function is very stable, an FSM implementation requires less gates and is faster compared with just using small, slow (compared to host CPU) embedded cores. Note, embedded cores can be used to aid and to support new functions.

* The QP and MTPT context is cached in the ASIC. ASIC vendor scaling of QP and MTPT context cache sizes to match the capabilities of new CMOS generations. Given CMOS circuit/area doubling trends, this allows at least a doubling of context size every 12-18 months. Further increases are possible when one considers that the rest of the ASIC logic doesn't need to double in size with each new ASIC generation.

* Both a reliable and unreliable transport is supported. Adapters that support the IB HCA specification must provide both. An iWARP RDMA enabled NIC (RNIC) can also support an unreliable transport (e.g. Layer 2 NIC or even UDP).

* Prefetch of WQE's, especially for Send and Shared Receive Queues to overlap I/O processing.

Vendors have implemented network adapters that support the RDMA Model and scale very well as the number of processes (and their associated QPs) is increased from 2 to 2049. For IB, Mellanox has posted an excellent paper showing the scaling bounds of their implementation, see: http://www.mellanox.com/pdf/whitepapers/PCIxVsMemfree_WP_100.pdf .

Programming over the RDMA Model

As with any programming model the success of its application depends largely on the method by which its semantics are implemented. When we created the InfiniBand RDMA Model, which was also the base we used for iWARP, some of us envisioned two programming models over the RDMA Model: one being the use of existing APIs over the RDMA Model and the other being the evolution of existing APIs and protocols to fully exploit the RDMA Model. Following is a description of how both of these programming models can take advantage of the RDMA Model.

There was no guidebook for mapping existing APIs (Sockets and MPI) that did not support memory registration over the RDMA Model. To help folks (e.g. SCSI, NFS, Sockets) map existing APIs over the RDMA Model, we observed the following:

* The layer between the API and the RDMA Model should support memory registration and two forms of data transfer, Send/Receive and RDMA Write/Read.

* Long lived memory registrations are used for Send/Receive data transfers. That is, the RDMA library performs a user space copy of the user's buffer into/out-of a long lived registered buffer.

* Dynamic memory registrations are used for RDMA Write/Read data transfers. That is, if the user space buffer isn't already registered (see 7th bullet in this list), the RDMA library dynamically registers the user space buffer.

* Memory registration has a finite number of deterministic CPU instructions, consisting of a context switching into the kernel, memory pinning by the kernel, memory registration with the adapter and a context switch back to user space.

* Out of user space memory copies also have a finite number of deterministic CPU instructions.

* If the overhead associated with buffer registration and de-registration exceeds the overhead associated with a user space buffer copy, then Send/Receive should be used. Otherwise RDMA Write/Read should be used. That is, Send/Receive should be used for control and small messages; and RDMA Writes/Reads for larger messages, where the cut-off between small and large is depends on the overheads (registration vs copy) associated with the OS/processor platform.

* Additionally, lazy de-registration algorithms were created to avoid the registration overhead for the case where the programmer re-uses buffers.

* For RDMA Writes and Reads, a buffer advertisement mechanism is necessary. The mechanism can be a-priori or a part of the programming model's wire protocol.

* The cost of scaling a reliable RDMA transport (IB Reliable Connected or iWARP) is analogous to the cost of scaling a reliable non-RDMA transport (e.g. TCP). That is, each connection must retain a context that is used for reliability checks. If reliability is required, then performing the reliability checks are required, whether they be performed in the host CPU or the adapter. If they are performed in the adapter, then to scale efficiently the adapter must have high bandwidth access to the context, just like the host CPU must have high bandwidth access to the context if the reliability check is performed on the host.

We also observed that the RDMA Model can be exploited ever further if the following are made visible to the programming model's API:

* Memory registrations. The Sockets Extensions standardized by the ICSC (see http://www.opengroup.org/icsc/uploads/40/6415/ES_API_1_0.pdf) support memory registration operations. This allows a user space program to perform a long lived registration of its buffer working space(s) and then transfer into/out-of those buffers without incurring any memory registration overhead. It eliminates the need to copy on Send/Receives and the need for a lazy de-registration algorithm. If you want to find out the state of these extensions, talk to your OS vendor.

* Asynchronous completions. Also standardized by the ICSC Sockets Extensions. This allows a user space program to post work to a QP through a Sockets library and continue processing without ever switching into kernel space. The user space program can then retrieve completions through asynchronous polls.

* RDMA Writes and Reads. Some of us tried to get these into ICSC Sockets Extensions 1.0, but it didn't make the 1.0 cut. Giving the user space program control of RDMA Writes and Reads enables a-priori usage models for small messages that exploit RDMA Write and Read semantics, such as the ability to perform a data transfer to a remote node without invoking a thread at the remote node. The uDAPL and the ICSC IT-API support RDMA Writes and Reads.

* Shared Receive Queues. This enables a more efficient WQE prefetch and buffer model at the receiver.

We now turn to the critique posted by Patrick Geoffray.

Response to Myricom's Geoffray Critique
Please note to conserve space in the list below, the following acronyms are used:

* VIA – Virtual Interface Architecture

* S/R – Send/Receive

* uDAPL – User Direct Access Provider Library

* IT-API – Interconnect Transport API

List of Myricom's Geoffray Critique versus “RDMA” Based Adapter Rebuttal: Critique —> Rebuttal.

1. VIA (1st RDMA standard) faded away. —> We used VIA as the base for IB Release 1.0, uDAPL and IT-API.

2. S/R uses local information for placement; RDMA requires memory registration. —> Out of user space data transfer is what requires memory registration for both S/R and RDMA.

3. MPI S/R requires the ability to match based on several criteria (Sender, Tag, Context). —> MPI S/R can be mapped over an RDMA (IB or iWARP) model's S/R and the matching mechanism can be implemented in software.

4. MPI S/R allows a message to be sent to multiple nodes. —> MPI S/R can use either a reliable (IB RC, iWARP) or unreliable transport (IB UD, UDP. To perform a reliable message send to multiple nodes, the reliable RDMA Model can be used, in which case the adapter performs the reliability checks. Otherwise the unreliable RDMA Model can be used, in which case the reliability checks must be performed in host software, which of course requires host CPU compute cycles. The latter may not be a problem if the host CPU is just doing data transfers, but if its doing other work (e.g. user space program computations), then obviously the reliability checks will increase the program's computation time.

5. MPI S/R allows a message to be sent even if the remote node has no buffer posted. —> MPI S/R can be implemented using an RDMA Model Shared Receive Queue, which the MPI driver can keep full. SRQs can be associated with either a reliable or unreliable QPs.

6. MPI S/R requires ordering between senders. —> When mapping MPI S/R over an RDMA Model's S/R, the software library/driver can add an ordering control to the message to provide ordering between senders.

7. MPI S/R can't make use of zero copy, doesn't state why. Presumably it's because buffers are dynamically registered. —> If the MPI program has a buffer working set, then MPI S/R can use lazy deregistration to avoid the registration overhead.

8. Sockets S/R can't make use of zero copy. —> Myricom's Geoffray statement is false. For programs that use Sockets Extensions 1.0, the user can statically register its user space working set, in one region if its contiguous in VA space, and reuse those buffers without incurring any registration overhead. These registered buffers can then be used to perform zero copy on both S/R and RDMA Writes/Reads. Additionally, the Sockets Direct Protocol (SDP) can be used to exploit RDMA for large messages.

9. To do zero-copy, local side needs to know where it's going to read/write the data on the remote side. —> Myricom's Geoffray statement is false. If Send/Receive is used, the local side doesn't need to know where the data is going in the remote side.

10 MPI sender has to wait for the MPI receiver to be ready before completing the communication and reusing the send buffer. —> Myricom's Geoffray statement is false. If Send/Receive is used, the local side doesn't need to know where the data is going in the remote side.

11. Most MPI implementations that claim zero-copy actually do a memory copy for small messages. The RDMA model does not help in any way. —> Myricom's Geoffray statement is false, the RDMA Model is more than RDMA Writes/Reads. When we created and standardized protocols that use the RDMA Model (SDP, iSER, NFS/RDMA) we observed that for small messages the RDMA Model's S/R mechanism is more efficient than RDMA Write/Reads. However, MVAPICH and Open MPI have implemented mechanisms to do RDMA transfers even for small messages. This does involve pre-registering a set of RDMA buffers and exchanging addresses and keys, but that only happens once during connection setup. Once everything is set up, even small message transfers show benefit of using RDMA, even with the attendant copy in/out of the RDMA buffers. There are questions of scalability with this, but it is a mechanism that is available for those that want to tune their MPI setup to use it.

12. Registration and deregistration provides the lowest overhead for large messages. Memory copies provides the lowest overhead for small messages. —> Myricom's Geoffray statement is false, long-lived registrations provide the lowest overhead.

13. With RDMA Write only one process can safely write into a remote buffer at a time. An RDMA buffer is required for each possible sender, receiver then looks for messages in N-1 locations (N = processes). —> Studies have shown that in distributed, parallel scientific applications, most processes only engage in point-to-point communications with a small number of peer processes (J. S. Vetter and F. Mueller. Communication Characteristics of Large-Scale Scientific Applications for Contemporary Cluster Architectures. In IPDPS, April 2002). This has led MVAPICH and Open MPI to move from fully-connected models to dynamic-connection models which limit the number of reliably-connected processes by using dynamic and adaptive connection management techniques. This, in turn, reduces overall resource usage and avoids the N-1 connection/scalability issues.

14. RDMA is a connected model. (a QP in one process is associated with a QP in a different process), requiring N-1 Receive Queue resources. —> True for 1st generation reliable (IB RC) transports. Not true for 2nd generation reliable (iWARP, IB 1.2 RC) transports, which implement Shared Receive Queues. Not true for unreliable (IB UD, UDP) transports.

15. Shared Receive Queue is inherently an S/R model, perhaps a sign that native RDMA interconnects are slowly migrating to the more efficient Send/Recv programming model. —> Standard RDMA Models have since day 1 supported Send/Receive and RDMA.
Upper level protocols (e.g. SDP, iSER, NFS/RDMA) over “RDMA” have since day 1 supported Send/Receive and RDMA.

16. SRQ does not address the overhead of initially establishing the connections, so a connection-on-demand mechanism is needed to hide the problem. —> Offloading a reliable (IB RC, iWARP) Send/Receive or RDMA transport to an adapter makes sense for long-lived connections. For short lived connections, because of the connection establishment/destruction overhead, its better to either use an offloaded unreliable transport (IB UD, UDP) or a host transport.

17. The RDMA programming model does not fit well with the two-sided semantic constraints of MPI or the Sockets interface. —> The RDMA programming model fits very well with both, as I've described in this rebuttal. For Sockets, I've described how the ICSC Socket Extensions 1.0 and SDP eliminate the memory registration issues Myricom's Geoffray raises. For MPI, both Mvapich and Open MPI have moved beyond N-1 RDMA connections and use dynamic and adaptive mechanisms for managing and restricting RDMA connections to large data transfers and frequently communicating processes. However, perhaps the RDMA programming model does not fit very well for some legacy network adapter implementations.
 
Short Critique on Host Transport Based HPC Adapters
 
There are a number of networking adapters that accelerate the transport layer but do not fully eliminate the transport layer from the host. For instance, layer-2 network accelerations have been available on Ethernet adapters for several years (e.g. checksum offload). In the HPC space some vendors accelerate the transport in the adapter, but still require the host to perform a portion of the transport reliability check processing. Given Myricom's Patrick Geoffray critique, it seems Myrinet adapters perform reliability checks in software running in the host CPU.

Adapters that do not fully eliminate data placement and transport layer functions from the host obviously have a higher CPU utilization cost than those that do. This cost is even higher if the host's transport layer processing must be performed in the kernel. If the adapter fully performs the data placement and transport layer functions, then the CPU overhead can be avoided because the transport completely resides in the adapter.

Does the above mean all adapters that perform a portion of the transport processing in the host are bad? No, Ethernet adapters that provide a layer-2 service work very well for short-lived connections and communications to clients. However, for cluster market segments, adapters that support the RDMA Model are a better fit than legacy adapters that perform a portion of the transport processing in the host.

It is interesting to note that almost twice as many new machines in the top100 are using InfiniBand than Myrinet and that Myrinet market share is being pinched by standard protocols, InfiniBand when high performance is needed and 1 Gbps Ethernet, soon 10 Gbps iWARP Ethernet, otherwise. Additionally, 3 machines in the top 10 use InfiniBand, whereas none use Myrinet. Apparently the RDMA Model scales sufficiently well to meet the needs of the high-end HPC market.

Conclusion
 
It is easy to see how the RDMA Model threatens legacy network adapters that have not evolved to its capabilities. The model fits well with the existing two-sided semantic constraints of MPI and the Sockets interface. It performs even better when the API evolves, such as the ICSC Sockets Extensions 1.0 evolution, to support RDMA Model capabilities, such as memory registration. The performance levels of the RDMA Model have been well published. Legacy network adapter vendors that don't support the RDMA Model usually point to the “inability to scale” myth claiming that for N processes to reliably talk to each other, N-1 process contexts are required in the network adapter. Of course, they often forget to mention that with any reliable transport N-1 process contexts are required somewhere to maintain end-end ordering guarantees. Perhaps the omission occurs, because most of these vendors perform the end-end ordering guarantees in the host CPU, which takes away cycles from the program that uses the adapter.

It is true that history always repeats itself, APIs and protocols are evolving to take advantage of the evolutionary step represented by the RDMA Model. However, like all evolutions, some legacy network adapter architectures will not be able to make the evolutionary step and will continue to struggle with a diminishing cluster market share.

The author would like to thank the following folks for their input during reviews of this article: Brad Benton, Jimmy Hill, Mike Ko, Rick Maule, Bernard Metzler and Claudia Salzberg.

—–

Renato Recio is an IBM Distinguished Engineer and Chief Engineer of IBM eSystems Networks. He was one of the founding and contributing engineers of Future IO (which merged with Next Generation IO to become InfiniBand), InfiniBand, iWARP (RDMA stack over TCP/IP) and iSER (iSCSI Extensions for RDMA). He also contributed to the Sockets Direct Protocol and helped in the founding of the ICSC. He has contributed to the architecture of several IBM RDMA and layer-2 networking adapters. He is currently co-chairing the PCI IO Virtualization Working Group, which is standardizing mechanisms that accelerate IO Virtualization and enable multiple hosts to share multi-root aware PCI Express switches and adapters.

Subscribe to HPCwire's Weekly Update!

Be the most informed person in the room! Stay ahead of the tech trends with industy updates delivered to you every week!

HPC Career Notes (March 2017)

March 1, 2017

In this monthly feature, we’ll keep you up-to-date on the latest career developments for individuals in the high performance computing community. Read more…

By Thomas Ayres

Intel Sets High Bar with Workforce Diversity Program Results

February 28, 2017

Intel’s impressive efforts to achieve workforce diversity and compensation equality edged up yet another notch last year according to the company’s 2016 Diversity and Inclusion Report released today. Read more…

By John Russell

Battle Brews over Trump Intentions for Funding Science

February 27, 2017

The battle over science funding – how much and for what kinds of science – Read more…

By John Russell

Google Gets First Dibs on New Skylake Chips

February 27, 2017

As part of an ongoing effort to differentiate its public cloud services, Google made good this week on its intention to bring custom Xeon Skylake chips from Intel Corp. Read more…

By George Leopold

HPE Extreme Performance Solutions

Manufacturers Reaping the Benefits of Remote Visualization

Today’s manufacturers are operating in an ever-changing atmosphere, and finding new ways to boost productivity has never been more vital.

This is why manufacturers are ramping up their investments in high performance computing (HPC), a trend which has helped give rise to the “connected factory” and Industrial Internet of Things (IIoT) concepts that are proliferating throughout the industry today. Read more…

Thomas Sterling on CREST and Academia’s Role in HPC Research

February 27, 2017

The US advances in high performance computing over many decades have been a product of the combined engagement of research centers in industry, government labs, and academia. Read more…

By Thomas Sterling, Indiana University

Advancing Modular Supercomputing with DEEP and DEEP-ER Architectures

February 24, 2017

Knowing that the jump to exascale will require novel architectural approaches capable of delivering dramatic efficiency and performance gains, researchers around the world are hard at work on next-generation HPC systems. Read more…

By Sean Thielen

Weekly Twitter Roundup (Feb. 23, 2017)

February 23, 2017

Here at HPCwire, we aim to keep the HPC community apprised of the most relevant and interesting news items that get tweeted throughout the week. Read more…

By Thomas Ayres

HPE Server Shows Low Latency on STAC-N1 Test

February 22, 2017

The performance of trade and match servers can be a critical differentiator for financial trading houses. Read more…

By John Russell

Thomas Sterling on CREST and Academia’s Role in HPC Research

February 27, 2017

The US advances in high performance computing over many decades have been a product of the combined engagement of research centers in industry, government labs, and academia. Read more…

By Thomas Sterling, Indiana University

Advancing Modular Supercomputing with DEEP and DEEP-ER Architectures

February 24, 2017

Knowing that the jump to exascale will require novel architectural approaches capable of delivering dramatic efficiency and performance gains, researchers around the world are hard at work on next-generation HPC systems. Read more…

By Sean Thielen

HPC Technique Propels Deep Learning at Scale

February 21, 2017

Researchers from Baidu’s Silicon Valley AI Lab (SVAIL) have adapted a well-known HPC communication technique to boost the speed and scale of their neural network training and now they are sharing their implementation with the larger deep learning community. Read more…

By Tiffany Trader

IDC: Will the Real Exascale Race Please Stand Up?

February 21, 2017

So the exascale race is on. And lots of organizations are in the pack. Government announcements from the US, China, India, Japan, and the EU indicate that they are working hard to make it happen – some sooner, some later. Read more…

By Bob Sorensen, IDC

TSUBAME3.0 Points to Future HPE Pascal-NVLink-OPA Server

February 17, 2017

Since our initial coverage of the TSUBAME3.0 supercomputer yesterday, more details have come to light on this innovative project. Of particular interest is a new board design for NVLink-equipped Pascal P100 GPUs that will create another entrant to the space currently occupied by Nvidia's DGX-1 system, IBM's "Minsky" platform and the Supermicro SuperServer (1028GQ-TXR). Read more…

By Tiffany Trader

Tokyo Tech’s TSUBAME3.0 Will Be First HPE-SGI Super

February 16, 2017

In a press event Friday afternoon local time in Japan, Tokyo Institute of Technology (Tokyo Tech) announced its plans for the TSUBAME3.0 supercomputer, which will be Japan’s “fastest AI supercomputer,” Read more…

By Tiffany Trader

Drug Developers Use Google Cloud HPC in the Fight Against ALS

February 16, 2017

Within the haystack of a lethal disease such as ALS (amyotrophic lateral sclerosis / Lou Gehrig’s Disease) there exists, somewhere, the needle that will pierce this therapy-resistant affliction. Read more…

By Doug Black

Azure Edges AWS in Linpack Benchmark Study

February 15, 2017

The “when will clouds be ready for HPC” question has ebbed and flowed for years. Read more…

By John Russell

For IBM/OpenPOWER: Success in 2017 = (Volume) Sales

January 11, 2017

To a large degree IBM and the OpenPOWER Foundation have done what they said they would – assembling a substantial and growing ecosystem and bringing Power-based products to market, all in about three years. Read more…

By John Russell

US, China Vie for Supercomputing Supremacy

November 14, 2016

The 48th edition of the TOP500 list is fresh off the presses and while there is no new number one system, as previously teased by China, there are a number of notable entrants from the US and around the world and significant trends to report on. Read more…

By Tiffany Trader

Lighting up Aurora: Behind the Scenes at the Creation of the DOE’s Upcoming 200 Petaflops Supercomputer

December 1, 2016

In April 2015, U.S. Department of Energy Undersecretary Franklin Orr announced that Intel would be the prime contractor for Aurora: Read more…

By Jan Rowell

IBM Wants to be “Red Hat” of Deep Learning

January 26, 2017

IBM today announced the addition of TensorFlow and Chainer deep learning frameworks to its PowerAI suite of deep learning tools, which already includes popular offerings such as Caffe, Theano, and Torch. Read more…

By John Russell

D-Wave SC16 Update: What’s Bo Ewald Saying These Days

November 18, 2016

Tucked in a back section of the SC16 exhibit hall, quantum computing pioneer D-Wave has been talking up its new 2000-qubit processor announced in September. Forget for a moment the criticism sometimes aimed at D-Wave. This small Canadian company has sold several machines including, for example, ones to Lockheed and NASA, and has worked with Google on mapping machine learning problems to quantum computing. In July Los Alamos National Laboratory took possession of a 1000-quibit D-Wave 2X system that LANL ordered a year ago around the time of SC15. Read more…

By John Russell

Enlisting Deep Learning in the War on Cancer

December 7, 2016

Sometime in Q2 2017 the first ‘results’ of the Joint Design of Advanced Computing Solutions for Cancer (JDACS4C) will become publicly available according to Rick Stevens. He leads one of three JDACS4C pilot projects pressing deep learning (DL) into service in the War on Cancer. Read more…

By John Russell

Tokyo Tech’s TSUBAME3.0 Will Be First HPE-SGI Super

February 16, 2017

In a press event Friday afternoon local time in Japan, Tokyo Institute of Technology (Tokyo Tech) announced its plans for the TSUBAME3.0 supercomputer, which will be Japan’s “fastest AI supercomputer,” Read more…

By Tiffany Trader

HPC Startup Advances Auto-Parallelization’s Promise

January 23, 2017

The shift from single core to multicore hardware has made finding parallelism in codes more important than ever, but that hasn’t made the task of parallel programming any easier. Read more…

By Tiffany Trader

Leading Solution Providers

CPU Benchmarking: Haswell Versus POWER8

June 2, 2015

With OpenPOWER activity ramping up and IBM’s prominent role in the upcoming DOE machines Summit and Sierra, it’s a good time to look at how the IBM POWER CPU stacks up against the x86 Xeon Haswell CPU from Intel. Read more…

By Tiffany Trader

BioTeam’s Berman Charts 2017 HPC Trends in Life Sciences

January 4, 2017

Twenty years ago high performance computing was nearly absent from life sciences. Today it’s used throughout life sciences and biomedical research. Genomics and the data deluge from modern lab instruments are the main drivers, but so is the longer-term desire to perform predictive simulation in support of Precision Medicine (PM). There’s even a specialized life sciences supercomputer, ‘Anton’ from D.E. Shaw Research, and the Pittsburgh Supercomputing Center is standing up its second Anton 2 and actively soliciting project proposals. There’s a lot going on. Read more…

By John Russell

TSUBAME3.0 Points to Future HPE Pascal-NVLink-OPA Server

February 17, 2017

Since our initial coverage of the TSUBAME3.0 supercomputer yesterday, more details have come to light on this innovative project. Of particular interest is a new board design for NVLink-equipped Pascal P100 GPUs that will create another entrant to the space currently occupied by Nvidia's DGX-1 system, IBM's "Minsky" platform and the Supermicro SuperServer (1028GQ-TXR). Read more…

By Tiffany Trader

Nvidia Sees Bright Future for AI Supercomputing

November 23, 2016

Graphics chipmaker Nvidia made a strong showing at SC16 in Salt Lake City last week. Read more…

By Tiffany Trader

Is Liquid Cooling Ready to Go Mainstream?

February 13, 2017

Lost in the frenzy of SC16 was a substantial rise in the number of vendors showing server oriented liquid cooling technologies. Three decades ago liquid cooling was pretty much the exclusive realm of the Cray-2 and IBM mainframe class products. That’s changing. We are now seeing an emergence of x86 class server products with exotic plumbing technology ranging from Direct-to-Chip to servers and storage completely immersed in a dielectric fluid. Read more…

By Steve Campbell

IDG to Be Bought by Chinese Investors; IDC to Spin Out HPC Group

January 19, 2017

US-based publishing and investment firm International Data Group, Inc. (IDG) will be acquired by a pair of Chinese investors, China Oceanwide Holdings Group Co., Ltd. Read more…

By Tiffany Trader

Dell Knights Landing Machine Sets New STAC Records

November 2, 2016

The Securities Technology Analysis Center, commonly known as STAC, has released a new report characterizing the performance of the Knight Landing-based Dell PowerEdge C6320p server on the STAC-A2 benchmarking suite, widely used by the financial services industry to test and evaluate computing platforms. The Dell machine has set new records for both the baseline Greeks benchmark and the large Greeks benchmark. Read more…

By Tiffany Trader

Intel and Trump Announce $7B for Fab 42 Targeting 7nm

February 8, 2017

In what may be an attempt by President Trump to reset his turbulent relationship with the high tech industry, he and Intel CEO Brian Krzanich today announced plans to invest more than $7 billion to complete Fab 42. Read more…

By John Russell

  • arrow
  • Click Here for More Headlines
  • arrow
Share This