Deployment Guide

3. Enter auditCfg --class 5 to enable the bottleneck detection audit log.
4. Once you have captured the discarded frame information, enter auditCfg --disable to disable audit
logging.
5. Enter auditDump -s to enable the bottleneck detection audit log.
An audit log entry for a discarded frame will look similar to the following :
<190>raslogd: AUDIT, 2014/04/11-23:12:04 (GMT), [AN-1014], INFO, FABRIC, NONE/root/
NONE/None/CLI, ad_0/STINGER3/FID 128, 7.3.0gcheung_v7.3.0_pit_a, , , , , , , Frame
unroute detected, tx port 0, rx port 46, sid 12e00, did 40a1600, timestamp 2014-04-11
23:
NOTE
The limit for trapping discarded frames is 20 frames per ASIC per second. As an
audit log is sent for every frame discard, the maximum number of audit logs
received per second can be very large (on the order of 1000 per second). This
“timeout storm” can make the system appear to be non-responding while it is
occurring. When all audit log entries have been received at the syslog server,
then any RASLogs that have been generated on the switch will be posted.
Advanced bottleneck detection settings
You can use the sub-second latency criterion parameters to refine the criterion for determining whether
a second is marked as affected by latency bottlenecks. For example, you may want to use the sub-
second latency criterion parameters in the following cases:
• You notice an under-performing application, but do not see any latency bottlenecks detected. You
can temporarily increase the sub-second sensitivity of latency bottleneck detection on the specific
F_Ports for this application.
• You want greater-than-default (sub-second) latency sensitivity on your fabric, so you set sub-second
latency criterion parameters at the time you enable bottleneck detection.
• You want to reduce the number of alerts you are receiving about known latency bottlenecks in the
fabric, so you temporarily decrease the sub-second latency sensitivity on these ports.
• You have a latency bottleneck on an ISL that is not at the edge of the fabric.
The sub-second latency criterion parameters are always applicable. These parameters affect alerts and,
even if alerting is not enabled, they affect the history of bottleneck statistics.
The following sub-second latency criterion parameters are shown with the default values in
parentheses:
• -lsubsectimethresh (0.8) is similar to the -lthresh alerting parameter, except on a sub-second level.
The default value of 0.8 means that at least 80 percent of a second must be affected by latency for
the second to be marked as affected.
• -lsubsecsevthresh (50) specifies the factor by which throughput must drop in a second for that
second to be considered affected by latency. The default value of 50 means that the observed
throughput in a second must be no more than 1/50th the capacity of the port for that second to be
counted as an affected second. 1/50th of capacity equals 2 percent of capacity, which translates to
98 percent loss of throughput.
Sub-second latency criterion parameters apply only to latency bottlenecks and not congestion
bottlenecks.
Advanced bottleneck detection settings
Fabric OS Administrators Guide 401
53-1003130-01