DOC PREVIEW
CORNELL CS 614 - Performance Evaluation of a Hardware Implementation of VIA

This preview shows page 1-2-3 out of 8 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Performance Evaluation of a Hardware Implementation of VIAXin LiuJune 8, 1999Department of Computer Science and EngineeringUniversity of California, San [email protected] IntroductionVirtual Interface Architecture (VIA) is the industry effort to standardize communicationparadigms for System Area Networks (SAN). Its design focuses on providing low-latency,high-bandwidth, end-to-end communication of two processes in the cluster. To achieve thisaim, VIA defines a set of functions, data structures and associated semantics to access thenetwork interface directly, bypassing the operating system in a fully protected fashion.Currenttly there are a few hardware implementations of VIA, such as the GigaNet, ServerNetand Finisar. Performance evaluation of hardware implementation is necessary to study thedesign of VIA. In this paper, we compare the performance characteristics of GigaNet withthose of Myrinet to study its advantage as a high speed network for cluster systems.We use a testbed consisting of 32 node HP NetServer cluster, each node having 2 PentiumII450MHz processors and installing NT Terminal Server 4.0. All the nodes are connected withMyrinet and GigaNet GNN1000. We implement Fast Message and MPI above GigaNet sothat we can use the existing parallel benchmarks and real applications to study itsperformance and compare the results with those from FM/Myrinet.This paper starts with a discussion of the architecture of VIA and FM, and then introduceswhy and how we implement FM on VIA. Then we study the performance of FM/GigaNet interms of in terms of latency, bandwidth, and scalability. And we also analyze the internalbehavior of GigaNet and compare it with Myrinet. We conclude with the overall evaluation ofGigaNet and VIA.2 Background and Motivation2.1 Virtual Interface Architecture (VIA)Virtual Interface Architecture is the industry effort to standardize communication paradigmfor System Area Networks (SAN). At its heart is the concept of an user-level networkarchitecture that that provides application processes a virtual view of a network interface toenable user-level access to high-speed communication devices. It removes theoperating system from the critical path of communications while still providing fullprotection. The key components of VIA include Virtual Instance, Message Descriptor, andSend/Receive Queue.GigaNet GNN1000 is a host adapter that implements VIA and provides reliablecommunication, in-order delivery, and support for RDMA-writes.2.2 Fast Message (FM)Fast Messages (FM) is a low-level messaging layer designed to deliver the underlyingnetwork's hardware performance to the application, even for small messages. For example,FM 2.1 on Myrinet delivers 41 megabytes/second for messages as short as 256 bytes witheven higher peak performance. FM makes bandwidth accessible, without requiring changes inapplications (or protocols) to increase the message size.Fast Messages (FM) is also designed to enable convenient and high performance layering ofother APIs and protocols atop it. As such it provides key guarantees: reliable, in orderdelivery, and host-network decoupling as well as a composable interface: efficientgather/scatter, receiver rate control, and per-packet multithreading which make it easy to buildhigher level interfaces based on FM. Some of the interfaces that have been built include MPI,Shmem Put/Get, and Global Arrays. Because the FM messaging layer is a simple, efficient setof primitives, it is appropriate for implementors of a language runtime or communicationslibrary or even the target of a compiler, in addition to application programmer use.2.3 Motivation for implementing FM on VIAThe main reason for implementation is that VIA does not provide a simple, efficientprogramming interface for user application. It provides some very low-level functions tooperate the VI instance and send and receive messages, but the users programs have to workon buffer management, flow control and connection management. The second reason is thatVIA does not provide enough functions for parallel programming. VIA only provides end-to-end communication and does not provide collective communication based on VIA. The end-to-end communication semantics is also not suitable for traditional SPMD parallel computing.User programs have to work on these issues themselves, which is tedious and error-prone. Aruntime library above VIA is necessary to make it a user-friendly programming interface.Here we choose Fast Message as the high-level user interface because of its simple andflexible API and variant applications.2.4 Implementation of Fast Message on VIA (FM/VIA)We implement Fast Message 2.1 based on VIA. FM/VIA keeps the same programminginterface as FM/Myrinet and the majority semantics. In FM/VIA, we just take VI as apowerful data link layer and provide reliable, in order, and flow control services on it.All FM applications can run directly on FM/VIA without any modification.Connection Management Because VIA is connection oriented, we set up connectionsbetween each pair of processes at the initialization and then a FM application can usethese connections to transfer data as if there is no connection at all. While FM/Myriuses the node ID and context number pair to identify a process, FM/VIA uses anetwork address and a discriminator pair to locate a process and setup connection.After initialization, the FM runtime just uses one connected VI for each process of theapplication.Buffer Management All the VI instances in a process share a pre-allocated Send Descriptorqueue and each descriptor has fixed-size registered memory. To send out a message, the FMruntime gets one descriptor from the free send queue, copies the data into the registeredmemory, and then posts the descriptor to Send Queue. After the complement of sending, thedescriptor is inserted into the free send queue again. At the receiver side, FM runtimeallocates and post receive descriptors to the Receive Queue of each VI instance. When amessage arrives, we get the receive descriptor out of the Receive Queue, process the message,and post the descriptor back to Receive Queue again. Each receive buffer has fixed sizelike the send side.In contrast to sharing send buffers, each VI instance has to allocate its own receive buffers.This is because VIA requires that the receive descriptors must be posted before any messagesarrive. One drawback of this approach is that it consumes too much memory and wastesmost of it when the number of


View Full Document

CORNELL CS 614 - Performance Evaluation of a Hardware Implementation of VIA

Documents in this Course
Load more
Download Performance Evaluation of a Hardware Implementation of VIA
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Performance Evaluation of a Hardware Implementation of VIA and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Performance Evaluation of a Hardware Implementation of VIA 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?