The SP2 High-Performance Switch

Stunkel, Craig B.; Shea, Dennis G.; Aball, B.; Atkins, M. G.; Bender, C. A.; Grice, Don; Hochschild, Peter; Joseph, Douglas J.; Nathanson, B.J.; Swetz, R.; Stucke, R.F.; Tsao, M.; Varker, Philip

doi:10.1147/sj.342.0185

Cited by 169 publications

(82 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Such controllers appear in the MIT Alewife machine [1], the KSR1 machine [15], the Stanford DASH multiprocessor [17], and the SGI Origin 2000 [16]. As o increases, the controller becomes less hardwired and more general-purpose, from specialized coprocessors like those in the Stanford FLASH multiprocessor [14] and the Sun S3.mp [22], through inexpensive off-the-shelf processors on the memory bus as in Typhoon-1 [23], to a controller on the I/O bus of the main processor like those in SHRIMP [3], and the IBM SP2 [28]. We also vary the node-to-network bandwidth from 400 MB/s (g 1 ) down to 25 MB/s (g 16 ), to analyze the effect of reducing network bandwidth on the applications under consideration.…”

Section: Design Spacementioning

confidence: 99%

Latency, occupancy, and bandwidth in dsm multiprocessors: a performance evaluation

Chaudhuri

Heinrich

Holt³

et al. 2003

IEEE Trans. Comput.

View full text Add to dashboard Cite

Abstract-While the desire to use commodity parts in the communication architecture of a DSM multiprocessor offers advantages in cost and design time, the impact on application performance is unclear. We study this performance impact through detailed simulation, analytical modeling, and experiments on a flexible DSM prototype, using a range of parallel applications. We adapt the logP model to characterize the communication architectures of DSM machines. The l (network latency) and o (controller occupancy) parameters are the keys to performance in these machines, with the g (node-to-network bandwidth) parameter becoming important only for the fastest controllers. We show that, of all the logP parameters, controller occupancy has the greatest impact on application performance. Of the two contributions of occupancy to performance degradation-the latency it adds and the contention it induces-it is the contention component that governs performance regardless of network latency, showing a quadratic dependence on o. As expected, techniques to reduce the impact of latency make controller occupancy a greater bottleneck. Surprisingly, the performance impact of occupancy is substantial, even for highly-tuned applications and even in the absence of latency hiding techniques. Scaling the problem size is often used as a technique to overcome limitations in communication latency and bandwidth. Through experiments on a DSM prototype, we show that there are important classes of applications for which the performance lost by using higher occupancy controllers cannot be regained easily, if at all, by scaling the problem size.

show abstract

Section: Design Spacementioning

confidence: 99%

Latency, occupancy, and bandwidth in dsm multiprocessors: a performance evaluation

Chaudhuri

Heinrich

Holt³

et al. 2003

IEEE Trans. Comput.

View full text Add to dashboard Cite

show abstract

“…Our study differs because we consider buffer space rather than buffer throughput limitation; also, we assume VOQs, and we study scheduler implementation. In an analogous way, the IBM SP2 Vulcan switch [15] used requests and grants to control the use of the limited throughput of its shared-memory buffer; again, we differ because we control buffer space rather than throughput. Recent PRIZMA work at IBM Zurich [16] considered a switch with VOQs and a limited shared-memory.…”

Section: Previous Workmentioning

confidence: 99%

Scheduling in switches with small internal buffers

Chrysos

Katevenis

2005

GLOBECOM '05. IEEE Global Telecommunications Conference, 2005.

View full text Add to dashboard Cite

Abstract-Unbuffered crossbars or switching fabrics contain no internal buffers, and function using only input (VOQ) and possibly output queues. Schedulers for such switches are complex, and introduce increased delay at medium loads, because they have to admit at most one cell per input and per output, during each time slot. Buffered crossbars, on the other hand, contain sufficient internal buffering (N 2 buffers) to allow independent schedulers to concurrently forward packets to the same output from any number of inputs. These architectures represent the two extremes in a range of solutions, which we examine here; although intermediate points in this range are of reduced practical interest for crossbars, they are nevertheless quite interesting for switching fabrics, and they may be of interest for optical switches. We find that tolerating two cells per-output per timeslot, using small buffers inside the switch or fabric, suffices for independent and efficient scheduling. First, we introduce a novel "request-grant" credit protocol, enabling N inputs to share a small switch buffer. Then, we apply this protocol to a switch with N such buffers, one per output, and we consider the resulting scheduling problem. Interestingly, this looks like unbuffered crossbar schedulers, but it is much simpler because it comprises independent, single-resource schedulers that can be pipelined. We show that individual buffer sizes do not need to grow, neither with switch size nor with propagation delay. Through simulations, we study performance as a function of the number of cells allowed per-output per-time-slot. For one cell, the switch performs very close to the iSLIP unbuffered crossbar with one iteration. For more cells, performance improves quickly; for 12 cells, packet delay under (smooth) uniform load is practically as low as ideal output queueing. Under unbalanced load, throughput is superior to buffered crossbars, due to better buffer sharing.

show abstract

“…Previous research [23,27] has recommended centralized buffer-pools over distributed buffers arguing that dynamic sharing of the central buffer pool leads to more efficient use of buffers. However, buffer efficiency is not a critical concern when we consider on-chip routers (such as the Alpha 21364 router [21]) where additional buffers are cheap.…”

Section: A Blam Implementationmentioning

confidence: 99%