next up previous contents
Next: A.2 Microbenchmark for the Up: A. Benchmark Methodologies Previous: A. Benchmark Methodologies   Contents

A.1 Microbenchmark for the $ B_{L}$ Parameter

The $ B_{L}$ parameter of our model provides two information related to the buffering system: (1) it displays the maximum number of buffer units associated to a switch's port, and (2) the associated buffering architecture adopted by this switching unit. As the primary usage of providing buffer storage is to handle temporary congestion, the natural starting point of our investigation is to create artificial congestion problem. For this communication microbenchmark, we carry out a set of tests that systematically generate traffics from multiple input ports (S) to a prefixed set of output ports (R). On each test, we start with a short burst of packets (of predefined volume and packet size), generated simultaneously from all the source nodes, and are flooded to the target destination nodes (ports). After injecting the burst into the network, all source nodes will stall for a specific duration, which is long enough for the switch's buffers to clear off their loading and for the receivers to count how many packets have they got. Then the program increases the burst volume, and continues the same process until the target burst volume is reached. By using different number of source nodes (S) and sink nodes (R) on each test, we collect a set of loss patterns which becomes the buffering signature of the switching unit in question.

Before discussing on how to draw the conclusion from the buffering signature, we first illustrate the theory behind our microbenchmark. Assuming that the network is error-free, all packet losses are caused by buffer overflow, either in the switch port or at the receiver node. The prerequisite of having buffer overflow is the unbalance of flow across the buffer region, so we simplify the bottleneck region as a staging buffer between input and output pipes, as shown in Figure A.1.

Figure A.1: Bottleneck stage phenomenon
\resizebox*{0.8\columnwidth}{!}{\includegraphics{figures/appdx/bottleneck.eps}}

Intuitively, the staging buffer starts queuing up data items when the departure rate is slower than the arrival rate. Thus, the ratio between the departure rate and arrival rate becomes a measure of congestion. Due to the limited size, this staging buffer cannot sustain long-term congestion, and eventually starts dropping all newly arrived packets when it is full.

Here we derive a deterministic model to delineate this overflow problem. Let the staging buffer be of size $ \tilde{B} $ units, and the arrival and departure rates over this bottleneck stage be A and D units per second respectively. Assume that at $ t=0 $, the staging buffer is empty, and with an unbalance flow ($ A>D $), packets start to cumulate over the staging buffer. Now at $ t=\beta $, the buffer becomes full, then we have

$\displaystyle \displaystyle A\cdot \beta =\tilde{B}+D\cdot \beta \qquad \Rightarrow \qquad \beta =\frac{\tilde{B}}{A-D}$ (A.1)

Therefore, when $ t\leq \beta $, the system can accommodate all arrivals and the success probability is equal to one. However, after buffer saturation, at $ t>\beta $, newly arrived packets can only be accepted and forwarded with a probability of $ \textstyle \frac{D}{A} $. Hence, we expect that the probability of success ($ \rho $) on moving k packets (where $ k>\tilde{B} $) across this bottleneck stage when $ A>D $ is:


$\displaystyle \rho$ $\displaystyle =$ $\displaystyle \frac{\left( k-\frac{A*\tilde{B}}{A-D}\right) *\frac{D}{A}+\frac{A*\tilde{B}}{A-D}}{k}$  
  $\displaystyle =$ $\displaystyle \frac{D}{A}+\frac{\tilde{B}}{k}$ (A.2)

We see from equation (A.2) that by varying these parameters, we are expecting to get different packet loss ratio:

Thus, by plotting the measured success ratio against the inverse of the burst volume (k), we would expect to get a linear equation, which has $ \tilde{B} $ as its slope and $ \frac{R*g_{s}}{S*g_{r}} $as its y-intercept. Besides, by using different combination of S and R, the resulting $ \tilde{B} $ value would reflect the internal buffer architecture adopted by that switching unit.

Table A.1: $ B_{L}$ parameters of different Ethernet switches
Switching unit Architecture $ B_{L}$
IBM 8275-326 Input-buffered 43
IBM 8275-326 (uplink) Input-buffered 45
IBM 8275-416 Output-buffered $ ^{\ddagger } $ 95
Intel 510T Shared-buffered 1990
Intel 510T (uplink) Shared-buffered 1990+510
Cisco Catalyst 2980G Output-buffered $ ^{\ddagger } $ 128
Cisco Catalyst 3524 Shared-buffered 650
Alcatel PowerRail 2200 Shared-buffered 820

$ \ddagger $$ \; $Both switches could be built on a shared-buffered architecture, but the buffer allocation scheme may impose an upper limit on each output buffer, hence, creates the output-buffered signatures.


Table A.1 summarizes the $ B_{L}$ parameters for some switches we have measured by using this microbenchmark. We also present the graphical signatures of three switching units in Figure A.2, which serve as the sample signatures to demonstrate how different buffer architectures look like under our microbenchmark.

Figure A.2: Microbenchmark signatures for (a)(b) IBM 8275-326, (c)(d) Cisco 2980G, and (e)(f) Intel 510T.
[IBM 8275-326 (Input-buffered)] \resizebox*{0.48\columnwidth}{!}{\includegraphics{figures/appdx/BL_326_1.eps}} [IBM 8275-326 (Input-buffered)] \resizebox*{0.48\columnwidth}{!}{\includegraphics{figures/appdx/BL_326_2.eps}}

[Cisco 2980G (Output-buffered)] \resizebox*{0.48\columnwidth}{!}{\includegraphics{figures/appdx/BL_2980_1.eps}} [Cisco 2980G (Output-buffered)] \resizebox*{0.48\columnwidth}{!}{\includegraphics{figures/appdx/BL_2980_2.eps}}

[Intel 510T (Shared-buffered)] \resizebox*{0.48\columnwidth}{!}{\includegraphics{figures/appdx/BL_510_1.eps}} [Intel 510T (Shared-buffered)] \resizebox*{0.48\columnwidth}{!}{\includegraphics{figures/appdx/BL_510_2.eps}}


next up previous contents
Next: A.2 Microbenchmark for the Up: A. Benchmark Methodologies Previous: A. Benchmark Methodologies   Contents