HP Fabric OS 7.1.0, Administrator'S Manual

Page: 376 / 666

376 Fabric OS Administrator’s Guide
53-1002745-02
Bottleneck detection overview
13
•
If the bottleneck detection feature detects ISL congestion, you can use ingress rate limiting to
slow down low priority application traffic, if it is contributing to the congestion.
Notes
•
Bottleneck detection is configured on a per-switch basis, with optional per-port exclusions.
•
Bottleneck detection is disabled by default. Best practice is to enable bottleneck detection on
all switches in the fabric, and leave it on to continuously gather statistics.
•
Bottleneck detection does not require a license.
Types of bottlenecks
The bottleneck detection feature detects two types of bottlenecks:
•
Latency bottleneck
•
Congestion bottleneck
A latency bottleneck is a port where the offered load exceeds the rate at which the other end of the
link can continuously accept traffic, but does not exceed the physical capacity of the link. This
condition can be caused by a device attached to the fabric that is slow to process received frames
and send back credit returns. A latency bottleneck due to such a device can spread through the
fabric and can slow down unrelated flows that share links with the slow flow.
By default, bottleneck detection detects latency bottlenecks that are severe enough that they
cause 98% loss of throughput. This default value can be modified to a different percentage.
A congestion bottleneck is a port that is unable to transmit frames at the offered rate because the
offered rate is greater than the physical data rate of the line. For example, this condition can be
caused by trying to transfer data at 8 Gbps over a 4 Gbps ISL.
You can use the bottleneckMon command to configure separate alert thresholds for congestion
and latency bottlenecks.
Advanced settings allow you to refine the criterion for defining latency bottleneck conditions to
allow for more (or less) sensitive monitoring at the sub-second level. For example, you would use
the advanced settings to change the default value of 98% for loss of throughput. See
“Advanced
bottleneck detection settings” on page 388 for specific details.
If a bottleneck is reported, you can investigate and optimize the resource allocation for the fabric.
Using the zone setup and Top Talkers, you can also determine which flows are destined to any
affected F_Ports.
How bottlenecks are reported
Bottleneck detection uses the concept of an affected second when determining whether a
bottleneck exists on a port. Each second is marked as being affected or unaffected by a latency or
congestion bottleneck, based on certain criteria.
The bottleneck detection feature maintains two histories of affected seconds for each port—one
history for latency bottlenecks and another for congestion bottlenecks. A history is maintained for a
maximum of three hours for each port. You can view the history using the bottleneckmon
--
show
command, as described in “Displaying bottleneck statistics” on page 391.
Bottlenecks are also reported through RASlog alerts and SNMP traps. These two alerting
mechanisms cannot be turned on and off independently.