03-24-2016 08:09 AM
Thanks for the suggestion. Just taken a look through the various 7.2, 7.3 and 7.4 release notes, and haven't found anything I think is relevant.
In the spirit of really thinking outside the box though, I copied some things that are kind of relevant, in case anyone here thinks they might be - I'd be suprised if this were the case tho:
FOS v7.2 allows buffer credit assignment even for “normal distance” (regular) E_ports
(We have E-Port Credit Configuration is not Enabled)
FOS v7.2 introduces a new CLI “creditrecovmode” to configure backend link credit loss recovery options
bottleneckMon CLI Change
FOS v7.3 deprecates the back-end credit recovery options in the bottleneckMon CLI. These options are supported via the existing creditRecovMode CLI.
Internal port credit recovery is Enabled with LrOnly
Back end port Loss of Sync's Link Reset is Disabled
C2 FE Complete Credit Loss Detection is Disabled)
E_Port Balance Priority Routing
FOS v7.3 enhances routing policy with the E_Port Balance Priority option. With this enhancement, when multiple paths to a domain exist, routing policy would assign routes so that the bandwidth demands from source ports are evenly distributed among all E_Ports.
(we have E_Port Balance Priority not set)
Link Reset on Loss of Sync
FOS v7.4 enhances credit recovery on backend links for 8G platforms by performing link reset (LR) on loss of sync (LOS) events. This enhancements applies to a port where a loss of sync is detected and the peer port of the backend link is on a 8G platform.
03-24-2016 09:48 AM
Antonio's suggestion (sanhealth) is a good heading to follow.
BUT, as important as the improvements, are the defects found and closed in each release. Looking at the FOS 7.4 release notes, there are some issues related to MAPS. One of them related to High usage reports in MAPS dashboards. I noticed two points above 100% in you attached graphic chart and it is the symptom of DEFECT000525068.
03-25-2016 04:53 AM - last edited on 03-25-2016 05:23 AM by Antonio Bongiorno TechHelp24
Our reports were too big so I had to run a SAN health without performance stats.
04-20-2016 12:44 AM
To be fairly honest unless you've seen an unusual drop in tx_crdt_timeout there is not an indication that different FOS code versions allow for an increase in bandwidth. I would start investigating the workload from a host perspective and correlate that to the numbers seen in the switch.
That being said the granularity of which MAPS is reporting on performance numers has significantly improved and may cause the increase in the total numer of events. Previous versions of fabricwatch did average out over a longer timeframe whereas MAPS with FPI is monitoring on a 2.5us interval. FOS 7.2 and up could report on sub-seconf latency but this had to be manually configured via the "bottleneckmon" command.
As you mentioned the phenomenon is simply a reporting observation and not related to a performance problem perse.
04-24-2016 09:13 AM - edited 04-24-2016 10:55 AM
if has given one command in FOS that was ever miscarriage, then a command is called "bottleneckmon"
as per my opinion, that command shold never existed.
......but as I said, is just my opinion