Buffer management strategies to reduce HoL blocking
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
summer project pal
Active In SP

Posts: 308
Joined: Jan 2011
29-01-2011, 07:40 PM

Buffer management strategies to reduce HoL blocking
A Seminar Reportby
Soumya Antony
Department of Computer Science & Engineering
College of Engineering Trivandrum
Kerala - 695016

.pdf   Buffer management strategies to reduce HoL blocking.pdf (Size: 994.38 KB / Downloads: 52)

1.1 Basic Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Traditional Queuing Options in Lossless ICTNs . . . . . . . . . . . . . . . . . . 6
1.3 New Solutions to the HoL Blocking Problem . . . . . . . . . . . . . . . . . . . 7
3.1 Congestion Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Selection of Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 DBBM and Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Topology and Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Mapping Schemes Evaluated . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Scalability of DBBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4 Fairness Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5 Comparison with Related Techniques . . . . . . . . . . . . . . . . . . . . . . . . 13

Congestion management is likely to become a critical issue in interconnection networks, as
increasing power consumption and cost concerns lead to improvements in the eciency of net-
work resources. In previous con gurations, networks were usually oversized and underutilized.
In a smaller network, however, contention is more likely to occur and blocked packets cause
head-of-line (HoL) blocking among the rest of the packets, spreading congestion quickly. The
best-known solution to HoL blocking is Virtual Output Queues (VOQs). However, the cost of
implementing VOQs increases quadratically with the number of output ports in the network,
making it unpractical. The situation is aggravated when several priorities and/or Quality of
Service (QoS) levels must be supported. Therefore, a more scalable and cost-e ective solution
is required to reduce or eliminate HoL blocking. This paper presents a family of methodolo-
gies, referred to as Destination-Based Bu er Management (DBBM), to reduce/eliminate the
HoL blocking e ect on interconnection networks. DBBM eciently uses the resources (mainly
memory queues) of the network. These methodologies are comprehensively evaluated in terms
of throughput, scalability, and fairness. Results show that using the DBBM strategy, with a
reduced number of queues at each switch, it is possible to achieve roughly the same throughput
as the VOQ mechanism. Moreover, all of the proposed strategies are designed in such a way
that they can be used in any switch architecture. To compare DBBM with RECN, a sophis-
ticated mechanism that eliminates HoL blocking in congestion situations. This mechanism is
able to achieve almost the same performance with very low logic requirements (in contrast with
Keywords: Communication/networking and information technology, network architecture
and design, computer systems organization.
CONGESTION management is one of the most critical and challenging problems intercon-
nect designers face today. Without suitable congestion management, network throughput may
degrade dramatically when the network, or even a small part of it, reaches saturation. Also,
packet latency may increase by several orders of magnitude.
The problems produced by congestion are much simpler to solve in lossy networks such as the
Internet because packets are dropped when congestion occurs, thus preventing the formation
of congestion trees .By doing so, the problem does not spread to neighboring regions in the
network. In this case, the main goal of congestion management is to minimize packet dropping
in order to reduce total packet latency and bandwidth wastage.
However, dropping packets in a parallel computer is not an acceptable solution. The as-
sociated multiple retransmissions may lead to some packets experiencing a very high latency,
which may have a direct impact on application execution time. As a consequence, most parallel
computers and high-performance clusters are based on lossless interconnects (e.g., Cray T3E,
IBM BlueGene/L, Myrinet 2000, Quadrics , In niBand, etc.). However, for lossless networks,
congestion has much more dramatic consequences. Congestion trees may grow very quickly
(depending on congestion severity), exhausting network bu er resources and preventing other
packets from making progress. A single hot spot may lead a large fraction of the network to
total collapse unless some action is taken.
Several interconnection subsystems have been introduced into the market over the last few
years, all of them with real solutions implementing a bidirectional multistage interconnection
network (BMIN). This is the case for Myrinet 2000, Quadrics, and In niBand. These intercon-
nect technologies are quite expensive compared to processor costs in current clusters. Thus,
there is a need to reduce the cost of the interconnect. Fortunately, all of these interconnects
allow the customer to decide how many processors will share a certain number of links, either
by using a di erent number of processors per node (e.g., by using a multiprocessor node), by
using a di erent number of network interface cards (NICs) per node, or by using a di erent
fraction of ports in the rst stage of the network to attach more processing nodes. Similar
considerations are also valid when attaching external disk subsystems to a server through a
storage or system area network (SAN). This
exibility allows the customer to reduce network
costs by reducing the number of communication components (i.e., switches and links) at the
expense of increasing link utilization, thus potentially driving the network as close to saturation
as possible.
On the other hand, power consumption is becoming increasingly important. As VLSI tech-
nology advances and link speed increases, interconnects are consuming an increasing fraction of
the total system power. There are only two ways of reducing network power consumption: 1)
reducing the number of links in the network (and using the remaining links more eciently) and
2) using some frequency/voltage scaling technique to reduce link power consumption. Unfor-
tunately, dynamic voltage scaling (DVS) techniques are quite inecient due to their extremely
slow response in the presence of trac variations and the suboptimal frequency/ voltage settings
during transitions.Arecent paper shows that static voltage scaling (SVS) combined with adap-
tive routing achieves higher performance and lower power consumption than DVS techniques,
in which the network does not saturate

In particular, congestion leads to blocked packets, which prevents the advance of other pack-
ets stored in the same queue. This may happen even if these packets are not addressed to the
congested area. This situation is referred to as head-of-line (HoL) blocking. Moreover, this
situation quickly spreads throughout the network, forming congestion trees. In this context,
congestion management becomes crucial achieving high network utilization without degrad-
ing performance when the network reaches saturation during trac peaks. The objective of
most classic congestion control techniques is to eliminate or prevent congestion from occurring.
However, this paper, provide a new approach to the problem.
1.1 Basic Idea
Remember that congestion is formed when several
ows of data (hereafter referred to as
ows) converge in a point on the network, provoking a contention which persists over
time. However, notice that the requested link cannot provide the service demanded by these

ows. Basically, the link is working at the maximum throughput. If the links leading to
these congested ports are working at 100 percent of their bandwidth, nothing can be done to
improve throughput unless link bandwidth is increased. Moreover, the aggregation of link-level

ow control across the links in the congestion tree collectively produces some backpressure,
which automatically limits packet injection at the sources sending packets to the congested
destinations. Indeed, the sources will adapt their injection rate to the available bandwidth
o ered by the congested destination.
The real problem is that congestion trees usually prevent other
ows (victimized
ows), not
destined to any of the congested ports, from running at the maximum speed allowed by the
network. In other words, the problem arises when hot
ows and victimized
ows share some
network resources (i.e., part of their route). In these cases, blocked packets (hot
ows) prevent
the advance of other packets stored in the same queue (victimized
ows). This situation is
known as HoL blocking. Thus, the HoL blocking caused by hot
ows is the real culprit of the
global throughput decrease and the latency increase of packets when congestion occurs.
From this alternative point of view of the congestion problem, an important observation
becomes apparent: if it were possible to eliminate or reduce the HoL blocking caused by hot

ows, congested situations would not a ect network performance. Thus, the objective is not
the prevention or elimination of hot
ows, but to prevent or reduce their negative in
uence on
1.2 Traditional Queuing Options in Lossless ICTNs
Every switch of a modern ICTN has a limited set of queues associated with every input and/or
output port; normally, the set cardinality is lower than the number of network endpoints. In
some cases, switches only have one queue per input port, e.g., Myrinet. Otherwise, whenever
using multiple queues per switch port, a queuing architecture and a suitable mapping policy
must be selected. Here, consider two main alternatives.
The rst one is to use VOQ at the network level (hereafter, VOQnet)/or at the switch level
(hereafter, VOQsw), i.e., hop-by-hop. In VOQsw, every input port has as many queues as
output ports, and an incoming packet is mapped to the queue associated with the requested
output port. Thus, HoL blocking at switch level is eliminated. However, HoL blocking at
network level can still occur between
ows sharing a subset of consecutive links along their
As a second option virtual channels (VCs) can be used, i.e., di erent queues with dedicated

ow control (FC. These channels can be load-balanced by allocating each outgoing packet to
the (currently) emptiest VC.
Even if these techniques perform well, they also exhibit important limitations. VOQnet has
poor scalability, VOQsw keeps high-order HoL blocking and VC may deliver packets out of
Recently, a dynamic solution has been proposed, referred to as RECN. RECN dynamically
allocates queues to congested points in the network thus separating congested trac from non-
congested one, thus eliminating the HoL blocking e ect. Although RECN achieves outstanding
results, it is designed for networks with sourcebased routing. Additionally, it requires new logic
at each switch.
1.3 New Solutions to the HoL Blocking Problem
An e ective mechanism to eliminate HoL blocking would need to have the following proper-
ties: scalability, fairness among the di erent
ows, low requirement of resources, and simplicity
to allow its implementation on current switches. This paper, proposes a new family of mecha-
nisms to resolve the HoL blocking problem, which will try to accommodate each of the properties
Packet destination distribution is an important issue with regards to the HoL blocking prob-
lem. As discussed in the previous section, it seems that the only way to completely eliminate
HoL blocking is by preventing congested
ows from sharing queues with noncongested
VOQ at network level works in this way, dedicating one queue per destination at every input
port. Here can see VOQ as a mechanism that assumes that all destinations may potentially
become congested, so it avoids mixing packets going to di erent destinations.
Trac across networks is not uniformly distributed over time. Packets traversing the network
are usually part of larger messages, and all of the packets belonging to the same message are
destined to the same node. Moreover, messages are usually a small fraction of the data being
transmitted from the same input to the same output. For example, aWeb client usually accesses
several Web pages, each one usually consisting of text, code, images, video, and/or audio. Each
image or audio/video clip usually consists of sequences of messages from the same source to
the same destination.
Temporal locality implies a correlation between packet destinations so that packets arriving
within a short period of time are likely to be destined to the same destination as previous
packets which arrived within the same interval.
Similarly, packets are not uniformly distributed across all the output ports or destinations.
Output ports leading to large Internet portals, Web servers, database servers, etc., are much
more heavily used than those that do not reach any server o ering these services. Therefore,
besides temporal locality, there is also spatial locality in packet destination. Another clear
example can be found in High- Performance Computing (HPC), where synchronization barriers
are implemented by accessing all of the processes with (located at di erent end nodes) the same
variable (located at one end node).
Spatial locality implies a correlation between packet destinations so that a large fraction of
the packets are destined to a small number of ports.

The DBBM scheme, aims to drastically reduce total queue requirements while keeping
roughly the same throughput as when using VOQs at the network level. This must be achieved
with a mechanism made to be as simple as possible. In order to do so, DBBM will take
advantage of temporal and spatial locality existing in packet destination distributions.
In DBBM, a small number of queues are used, signi cantly lower than the number of nal end
nodes in the system. In order to achieve its goals, DBBM relies on the following key decision:
a packet is mapped on the same queue ID regardless of the switch where it is being mapped.
That is, the mapping function used to implement DBBM does not consider (neither directly
nor indirectly) the current switch in order to compute the corresponding queue for a packet.
VOQsw does not map a packet on the same queue ID on every switch, as the queue ID
depends on the computed output port, which may be di erent at each hop. On the contrary,
VOQnet follows this way of mapping packets, as the queue ID is computed exclusively from
the packet's nal destination ID. Thus, in DBBM, use the same approach used in VOQnet;
however, DBBM uses a very low number of queues.
In DBBM, packets with the same destination are mapped in the same queue. However, as the
number of queues is signi cantly smaller than the number of destinations, packets with di erent
destinations end up being stored in the same queue. Thus, here need a mapping function able to
map all of the possible destinations in a small set of queues. Fig. shows the DBBM mechanism.
As in VOQnet, DBBM relies only on the packet's destination ID to compute the receiving queue
at the mapping function. However,only a subset of the bits of the packet's destination ID is
used for computing the queue. In particular, for a system with M end nodes (the end node is
coded with logM bits) and a DBBM mechanism with N queues (N is signi cantly lower than
M), only logN bits are selected from the destination ID of the packet. The selection process to
decide which bits are used to compute the queue must be chosen carefully in order to reduce
HoL blocking. In particular, DBBM tries to exploit packet destination locality to minimize
the number of times incoming packets with di erent destinations are stored in the same queue,
thus reducing HoL blocking.
As each queue in DBBM only stores packets for a subset of end nodes, it can be viewed as if
the physical outputports of the network are grouped into smaller sets of logical output ports,
and a queue is used at each node to map only packets destined to a particular logical output
port (i.e., VOQnet at the logical port level).
HoL blocking is partially eliminated by preventing packets destined to di erent logical ports
from being stored in the same queue. This technique should be designed in such a way that
the total number of queues and the number of destinations mapped per queue (the size of
the logical port) reduce the HoL blocking e ect to a minimum. Therefore, there is a trade-o
between e ectiveness (maintaining performance) and cost (measured by number of queues).
The main advantage of sharing a queue among several destinations is simplicity. The only
requirement is a suitable mapping function implemented on hardware. Basically, incoming
packets are allocated in the queue whose ID is computed by the mapping function. Also, note
Figure 1: DBBM on an input port of a switch
that in-order delivery is guaranteed because packets for a given destination use the same queue
at each port.
3.1 Congestion Isolation
DBBM relies on a static mapping function, that is, the static allocation of a xed set of
destinations to a de ned queue. By doing this, those packets belonging to hot
ows are always
mapped to the same queue. Thus, although HoL blocking is not completely eliminated, the
number of victimized
ows that su er the consequences of the HoL blocking is bounded. Take,
for instance, a system with 1,024 end nodes using an MIN network made of 8 x 8 switches with
DBBM at every input port with just 16 queues. If an end node congests, then only packets
addressed to 64 end nodes (out of 1,024, a 6.25 percent) may experience HoL blocking from
the congested node. The rest of the packets (addressed to 960 end nodes, a 93.75 percent) do
not interfere with the congested node.
Also, it must be noted that the number of end nodes a ected by a congested situation depends
on the number of queues used in DBBM. In the previous example, if DBBM is implemented
at switches with 32 queues (instead of 16 queues), then a congested destination only interferes
with packets addressed to 32 end nodes out of 1,024, a 3.12 percent.
3.2 Selection of Bits
The selection of the bits extracted from the destination ID may a ect the nal performance of
the mechanism. If a subset of the lowest order bits is used, packets to di erent destinations are
stored cyclically (consecutive destination addresses mapped to di erent queues). This method
is referred to as modulo mapping (or cyclic mapping), e.g., for a network with 256 destinations
and 16 queues, the four least signi cant bits of the destination ID (8-bit eld) point to the
queue to map the
ow into.
On the other hand, if a subset of the highest order bits is used, packets to di erent destinations
are stored in linear blocks (consecutive destination addresses mapped to the same queue). This
method is referred to as block mapping. There are also intermediate options, like block-cyclic
The way in which select the bits to compute the queue may depend on di erent issues. The
most intuitive one is the trac. However, as a static mapping mechanism, nothing can be done
to adapt to the dynamic variations of trac.3 Simulations will show the most suitable mapping
function for a given topology.
3.3 DBBM and Flow Control
DBBM can be implemented on top of a system with
ow control mechanisms. The main
requirement for implementing
ow control is to precompute the receiving queue for a packet at
the previous switch, in order to check its availability before injecting the packet (either using
creditbased or status-based
ow control).
As DBBM uses the same mapping function on every switch, the
ow control implementation
may be even simpli ed. The mapping function just delivers the receiving queue ID at the
current switch (for mapping the packet). This ID may also be used for
ow control purposes,
as the packet is forwarded to the queue with the same ID at the downstream switch.
4.1 Topology and Routing
Three topologies have been used: single stage, multistage networks, and 2D/3D meshes.
The multistage interconnection network (MIN) models a bidirectional MIN (BMIN) built from
8-port switches interconnected in a perfect shue pattern. To evaluate the di erent mapping
strategies, di erent network con gurations are de ned. Each con guration is de ned by the
total number of input and output ports of the network. In BMINs, deterministic routing has
been applied. For the 2D mesh network, an 8 x 8 topology is evaluated with either one and
four end nodes attached to each switch. Dimension order routing is used.
4.2 Mapping Schemes Evaluated
The six queuing and mapping schemes evaluated are described next, ordered by increasing
1. Single FIFO (1Q): 1Q sets the lower bound of performance, that of a single queue with
FIFO service. As the simplest queuing structure, even in single-stage fabrics with uniform
trac, the 1Q scheme is theoretically limited to 58 percent throughput.
2. DBBM NQ: DBBM with modulo-N mapping, N being the number of queues, that is, the
logN least signi cant bits of the destination ID points to the queue to map the
ow into.
3. Load-balanced (EMPTIEST): EMPTIEST is a load-balancing scheduling strategy, i.e.,
packets are mapped to the queue with the lowest current occupancy. This mapping is based
on the queue status of the next/downstream switch.
4. Uniform distribution (RANDOM): In random queue mapping strategy, whenever a new
packet arrives at a switch, it is mapped on a randomly selected queue.
5. VOQsw: VOQsw is the typical VOQ scheme implemented in most modern ICTNs. It
applies a link-level VOQ at every hop, i.e., switch will have at every input port as many queues
as output ports.
6. VOQnet:VOQnet sets the upper bound of performance, that of an end-to-end VOQ scheme
globally applied across the entire ICTN. VOQnet requires in every port at every switch and at
every IA as many queues as destinations in the network. Its main use here is as a reference for
other, more practical, schemes.
4.3 Scalability of DBBM
Figs. show the results for 64 x 64; 512 x 512, and 1024 x 1024 BMINs, respectively.As can
be observed, 1Q, RANDOM, and EMPTIEST do not work at all. As the congestion tree re-
mains in the network their throughput degrades signi cantly. Speci cally, the achieved network
throughput is just a 0.02 percent (9 bytes/ns out of 400 bytes/ns) for 1,024 x 1,024 BMIN and
0.01 percent (9 bytes/ns out of 800 bytes/ns) for 2,048 x 2,048 BMIN (not shown). These
extremely low percentages indicate that the network has been
ooded by packets belonging to
the congestion tree.
Figure 2: Scalability study. BMIN networks. Accepted trac versus simulated time. (a) 64 x
64 BMIN. (b) 512 x 512 BMIN. © 1,024 x1,024BMIN.
Focusing on VOQsw, observe that as network size increases, the network throughput achieved
decreases. For the 64 x 64 BMIN, VOQsw achieved 74 percent (20 bytes/ns) of the maximum
achievable throughput (27 bytes/ns). With the 512 x 512 BMIN, its throughput decreases
signi cantly to 40 percent (80 bytes/ns out of 200 bytes/ns). An equal e ect occurs for 1,024 x
1,024 and 2,048 x 2048 BMINs. In particular, the achieved throughput is only 30 percent (120
bytes/ns out of 400 bytes/ns) and 26 percent (210 bytes/ns out of 800 bytes/ns).
On the other hand, DBBM maintains the performance irrespective of the BMIN size. For
the 64 x 64 BMIN, DBBM is almost able to reach the maximum performance with only four
queues (96 percent, 26 bytes/ns out of 27 bytes/ns). With the 512 x 512 BMIN, its throughput
is 92 percent (185 bytes/ns out of 200 bytes/ns). This decrease is even less signi cant for 1,024
x 1,024 and 2,048 x 2,048 BMINs. For these BMINs, the achieved network throughput stays
around 91.5 percent (366 bytes/ns out of 400 bytes/ns) and 90 percent (723 bytes/ns out of
800 bytes/ns). Moreover, with only eight queues (and upward), DBBM achieves a throughput
of 97 percent for 1,024 x 1,024 and 2,048 x 2,048, and 99 percent for 64 x 64 and 512 x 512.
To sum up, DBBM is able to roughly maintain the maximum performance when the BMIN
size increases, using a small number of queues.
4.4 Fairness Evaluation
DBBM exhibits good performance for uniform (low and high loads) and hot spot trac. It
also performs well in terms of scalability. However, as it maps di erent
ows into the same
queue, it introduces a degree of unfairness.
With DBBM, the number of
ows a ected by HoL blocking depends more on the number
of queues used than the routing algorithm. DBBM guarantees that only a de ned set of
destinations is a ected by a congested
ow as only a de ned set of
ows will share a queue.
However, when using VOQsw,
ows sharing a queue are not always the same during their trip
along the network, the reason for having a larger degree of unfairness.
4.5 Comparison with Related Techniques
One of the main restrictions of the techniques proposed in this paper is keeping them as
simple as possible, in such a way that they can be applied to any ICTN, regardless of the
network architecture. This led to a deterministic use of queues. However, the philosophy of
Figure 3: RECN and DBBM Memory Requirements
dynamically detecting and isolating congestion can also be used to eliminate HoL blocking inside
the network. In fact, Regional Explicit Congestion Noti cation (RECN) has been identi ed as
the rst truly e ective method for eliminating HoL blocking in a scalable way. In this section,
this mechanism is brie
y described and compared with DBBM.
Basically, RECN works as follows: a switch that detects congestion at any of its ports
noti es any one of the upstream switches sending packets addressed to the congested point.
The congested port is then considered the root of a congestion tree that is being formed inside
the network. Likewise, when a switch receives a congestion noti cation, it allocates a dedicated
queue to store only those packets that will pass through the congested port. These packets are
identi ed by comparing the route included in their headers to the route going from the current
point to the route. Switches receiving congestion noti cations are considered to be at branches
of the congestion tree (referred to as branch switches).
Contrary to the main property (simplicity) pursued in the mechanisms proposed in DBBM,
RECN is more complex. This is due to the following reasons:
RECN detects and isolates packets forming congestion trees originated either at endpoints or
inside the network. Therefore, a proper mechanism for identifying internal hot spots is required.
In particular, RECN uses a detection threshold value at each queue for detecting congestion.
Whenever the occupancy of a queue reaches the threshold, the congestion noti cation mecha-
nism is triggered.
In its current form, RECN can only be applied to networks with deterministic source-based
routing. The reason is that the special method for routing in source-based networks allows the
identi cation of internal hot spots in the network. On the other hand, DBBM can be used
in almost all of the networks with source or distributed routing, and deterministic or adaptive
To keep track of congestion trees, RECN requires speci c and new control memories at both
input and output ports on every switch. On the other hand, DBBM, in general, requires only
a selection function, and in some cases, e.g., In niBand, no switch modi cations at all.
For a typical RECN implementation, eight set-aside queues (SAQs) are required at each
input port to store incoming packets. In addition, control structures are also required at each
input and output port of a switch. Contrary to that DBBM does not require large amounts
of memories nor control information related to congestion. The numbers provided in the table
have been obtained assuming a credit-based
ow control mechanism and a two credit threshold
at the SAQs to trigger congestion noti cations.
In all the cases, DBBM achieves maximum performance when using 16 queues. RECN also
achieves maximum performance, although it experiences transient HoL blocking due to its
aggressive use of queues (initially, RECN uses only one queue to store all incoming packets
until congestion is detected). Therefore, RECN su ers a transient e ect not present in DBBM.
It is worth mentioning that the performance achieved by DBBM has been achieved with the
same memory requirements as RECN (and less logic requirements).
In order to reduce HoL blocking, a number of queuing schemes and mapping methods have
been proposed. Theoretically, only a full end to end VOQ or at least a subset of noninterfering

ows is able to completely eliminate HoL blocking. However, this solution is not scalable to
large ICTNs.
Simulation results have con rmed that both link/switchlevel VOQ (VOQsw) and destination-
oblivious load-balancing (EMPTIEST) schemes su er from high-order HoL blocking. On the
other hand, for a moderate increase in complexity, DBBM shows clear improvements, linearly
proportional to the number of operating queues. Independent of the network size, DBBM with
eight queues has achieved roughly the same throughput as the ideal VOQ, while using only a
small fraction of the queues.
Except for VOQnet, all of the mapping strategies introduce some degree of unfairness. How-
ever, DBBM kept the unfairness independent of the topology and the routing in use. For
DBBM, the number of
ows a ected by the congestion tree depends more on the number of
queues than on the routing algorithm used, whereas for VOQsw, the
ows a ected not only
depend on the mapping function but also on the routing algorithm.
[1] Jose Duato, Teresa Nachiondo, Jose Flich "Bu er management strategies to reduce hol
Vol. 21(No.6), 2010.
[2] T. Nachiondo, J. Flich, and J. Duato, "Destination-Based HoL Blocking Elimination,"
Proc. 12th Intl Conf. Parallel and Distributed Systems (ICPADS), July 2006.
[3] J. Duato, J. Flich, and T. Nachiondo, "Cost-E ective Technique to Reduce HoL Blocking in
Single Stage and Multistage Switch Fabrics," Proc. Euromicro Conf. Parallel, Distributed
and Network Based, pp. 48-53, Feb. 2004.


Important Note..!

If you are not satisfied with above reply ,..Please


So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page

Quick Reply
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
  Database management concepts seminar tips 9 3,818 23-07-2016, 02:17 PM
Last Post: Dhanabhagya
  crime file management system er diagram jaseelati 0 441 17-01-2015, 04:35 PM
Last Post: jaseelati
  cyber cafe management system ppt jaseelati 0 296 07-01-2015, 01:31 PM
Last Post: jaseelati
  online crime management system jaseelati 0 263 30-12-2014, 01:46 PM
Last Post: jaseelati
  crime file management system ppt jaseelati 0 229 27-12-2014, 01:17 PM
Last Post: jaseelati
  Content Management System (CMS) seminar ideas 10 6,302 20-03-2014, 04:30 PM
Last Post: navasfiroz
  uideline on Selection of Library Management System seminar poster 0 405 29-10-2013, 01:12 PM
Last Post: seminar poster
  Memory Management: Overlays and Virtual Memory ppt seminar projects maker 0 490 20-09-2013, 04:57 PM
Last Post: seminar projects maker
  Report on Management Information Systems seminar projects maker 0 537 14-09-2013, 04:26 PM
Last Post: seminar projects maker
  Data Mining, Banking Sector, Risk Management Report seminar projects maker 0 521 14-09-2013, 02:29 PM
Last Post: seminar projects maker