11-28-2011 08:59 AM
Can someone tell me what this counter indicates when it's clocking up on certain ports? I know what the various link control frames are but I don't know what this specific counter is telling me, if anything. It does seem to go hand in hand with ports that are experiencing congestion. For example:
stat_wtx 1036053469 4-byte words transmitted
stat_wrx 144865388 4-byte words received
stat_ftx 284207274 Frames transmitted
stat_frx 691755505 Frames received
stat_c2_frx 0 Class 2 frames received
stat_c3_frx 691745666 Class 3 frames received
stat_lc_rx 4600 Link control frames received
stat_mc_rx 0 Multicast frames received
stat_mc_to 0 Multicast timeouts
stat_mc_tx 0 Multicast frames transmitted
tim_rdy_pri 2 Time R_RDY high priority
tim_txcrd_z 4283176 Time TX Credit Zero (2.5Us ticks)
tim_txcrd_z_vc 0- 3: 0 0 0 2134951
tim_txcrd_z_vc 4- 7: 2148225 0 0 0
tim_txcrd_z_vc 8-11: 0 0 0 0
tim_txcrd_z_vc 12-15: 0 0 0 0
11-28-2011 10:40 AM
I honestly don't know, but your asking this in regards to performance problems?
If so, look at counters like c3 class discard due to timeouts, tim_txcrd_z and received/sent frames.
But first reset the counters as the values can wrap round very quickly and are meaningless if you don't know when that happend.
Than take another look an hour or so later.
I prefer the command portstats64show as those value take considerable longer to wrap round.
11-28-2011 10:44 AM
Well, they are having problem but at this point we don't know if the congestion is part of it. This is in a BladCenter H with PS704 blades and they have various link issues, CRCs and other odd behavior but I think a majority of it has to do with them not having things setup for 'best practice'. They're not discarding any frames, so it's not choking the pipe to that point. They have some things to flash and retest and if that fails then we'll be gathering a fresh set of support saves as the ones I currently have are stale and not baselined at all. Thanks for the reply!
11-28-2011 10:57 AM
I'm not familiar with IBM gear, but are those perhaps the first 8G devices or longdistance involved?
If so, look at the portcfglongdistance setting and compare those to the IBM advised setting.
11-28-2011 11:24 AM
Well, they are technically first gen 8G devices for the Bladecenter (Emulex Tetra HBAs) , and the BCs have thier own special set of problems at 8G. This is not a long distance haul either, just within the same datacenter.
11-28-2011 02:30 PM
Made an error, I wrote portcfglongdistance I ment to write portfcgfillword.
If they are 8G devices how is the fill word set against that/those port(s) and what does IBM recommend?
11-29-2011 07:13 AM
portcfgfillword is set to 1 on internal switchs because it's an IBM recommandation / default config.
Have a look at the following and see if your configuration is concerned or not :
Hope this helps
11-29-2011 07:33 AM
Heh heh, thanks, but I'm one of the ones who came up with that document. I'm with product engineering for IBM BladeCenters and specialize in the FC side of things. I'm really just trying to find out what that specific counter is telling me.
11-29-2011 08:29 AM
It counts the received link control frames like,
|ACK||Acknowledge data frame (success)|
|F_RJT||Fabric frame reject|
|P_RJT||Port frame reject|
I wouldn't worry about it in case there ack''s.