SOLVED
Hard to say without any other evidence (Network logical/physical Topology? configuration files? involved Switches' logs? relevant Hosts and Services? Switching/Routing configurations? etc.).
AFAIK actually there is K.16.02.0016 software version.
But...without any correlated logs (especially during the slowdown) it's really difficult to imagine what is the cause (or what are the causes) of your network traffic random slowness (the culprit couldn't be exactly the core Switch...but a service or a host that is impacting - like doing a sort of DoS "Denial of Service" - your core Switch's switching/routing capabilities).
I'm not an HPE Employee
If I were you I would give K.16.02.0016 a try (or, if you don't feel brave enough [*], at least K.16.02.0014): starting with the K.16.02.0014 software build the TCP Push Preserve mode [**] parameter was set to disabled by default (it was enabled by default).
The TCP Push Preserve mode parameter set to disabled could be of help in very busy networks (very busy interfaces) - so, at least, check its status - and very busy networks can be easily found when you start having many concurrent 10Gbps (up)links to Servers and/or to other Switches; if I'm correct...you have the F Slot equipped with a HPE 8-port 10GbE SFP+ v2 zl Module (J9538A)...so a look at traffic of F1-F8 ports would be of help (also open an eye about overprovisioning [***] of 10Gbps ports).
[*] IMHO using K.16.02.0012, 0014 or 0016 is not particularly relevant when you're considering the most stable software argument...indeed you're using the latest K.16.02 software branch (and not a maintenance one) in all cases.
[**] From latest Release Notes:
"The TCP Push Preserve mode determines the queuing of the TCP packets that have the PUSH flag set. When this mode is enabled and the egress queue is full, TCP packets with the PUSH flag set are queued at the head of the ingress queue for egress queue space. This may delay subsequent incoming packets in the same queue and create a head-of-line blocking situation. When this mode is disabled and the egress queue is full, TCP packets with the PUSH flag set are dropped from the head of the ingress queue. If the current switch TCP Push Preserve mode has been set to DISABLED, it will be preserved as DISABLED and the corresponding configuration entries will be suppressed. If the current switch TCP PUSH preserve mode has been set to ENABLED, it will be changed to DISABLED and the change will be noted in system event logs as The tcp-push-preserve feature was disabled. This is a change to default configuration. The CLI command show tcp-push-preserve indicates the status of TCP push mode ENABLED/DISABLED. CLI command [no] tcp-push-preserve changes the status of TCP push mode."
[***] read this (could be of help, in any case).
I'm not an HPE Employee
What's about:
trunk A24,B21 trk1 trunk
that's a static (Non-Protocol) Ports Trunk with Port 24 (Slot A Module) and Port 21 (Slot B Module) as member ports to where? why static (so non LACP IEEE802.3ad)?
Then (I'm a little bit puzzled here):
interface F8 lacp active name "VDI" exit
is a little bit of a non sense (a single Port set as LACP Active?)...no trunk assignment here (I mean: no LAG). What's the purpose of setting "LACP Active" on a single port - Port 8 of Module on Slot F (6) - if LACP is used in Port Trunking (so with LAG) configurations?
I guess you're using a single 10Gbps port (F6) to connect to a Virtual Machine's OS on a Hypervisor or to a OS installed directly on a bare metal Desktop Server machine (in both cases through a physical 10Gbps NIC's port on a Server host) to provide VDI Virtual Desktop Infrastructure connectivity. Is it right?
I'm not an HPE Employee
