HP Fabric OS v7.0.1, Administrator'S Manual

Page: 336 / 584

298 Fabric OS Administrator’s Guide
53-1002446-01
Bottleneck detection overview
13
You configure bottleneck detection on a per-switch basis, with optional per-port exclusions.
NOTE
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 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.
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 a history of affected seconds for each port—one history
for latency 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 307.
Bottlenecks are also reported through RASlog alerts and SNMP traps. These two alerting
mechanisms are intertwined and cannot be independently turned on and off. You can use the
bottleneckMon command to specify alerting parameters for the following:
•
Whether alerts are to be sent when a bottleneck condition is detected
•
The size of the time window to look at when determining whether to alert