As a support-guy you very often look at port counters. These do not only provide insight into the status of a port but also may give statistical information which allows you to plan and design new connectivity layouts and diagrams or give some general advice. If you look at the wrong counters though you may be in for a surprise as some may not tell you the actual truth.
Here’s a snippet:
portstatsshow 1
stat_wtx 381282228 4-byte words transmitted
stat_wrx 308822249 4-byte words received
stat_ftx 77700965 Frames transmitted
stat_frx 752012412 Frames received
So what does this tell me? Well it shows me that a certain number of 4-byte words have been transmitted in such-and-so number of frames. This means you can do some calculations to try and determine the average frame-size which is handy if you need to configure long distance link. You can then determine the number of buffer-credits you need for that link.
So to do the maths you would need to multiply the stat_wtx by 4 which gives you the number of bytes and divide that by the stat_ftx value which in turns gives you (381282228*4)/77700965~19 bytes…..
Huh????
A standard frame header is already 24 bytes so what’s going one here?
Another example:
portstatsshow 2
stat_wtx 3756107161 4-byte words transmitted
stat_wrx 3232438475 4-byte words received
stat_ftx 3940733265 Frames transmitted
stat_frx 793324639 Frames received
results in (3756107161*4)/3940733265 ~ 4 bytes…….
How in world is that possible.
Well fairly simple. In this particular case the values do not tell the whole truth. The values represented by the portstatsshow command are 32-bit which results in a maximum value of 4294967295 after which it wraps back to 0 and starts over. As you can imagine the stat_w(r|t)x counters wrap much quicker than the stat_f(r|t)x counter and basically results in a very skewed value and renders everything useless.
There are two way to obtain more accurate values.
- Clear these counters with the “statsclear” command and looks at the values before they wrap. (On busy systems this can be pretty quick though.)
- Upgrade your switches to FOS 7.2.0 or higher. These include two 32-bit integer values of which the first integer keeps track of the amount of times the second has wrapped. Basically this add then up to be a 64-bit counter.
If you check the same example but now for via the portstats64show command you’ll see this:
portstats64show 1
stat64_wtx 27136 top_int : 4-byte words transmitted
346392029 bottom_int : 4-byte words transmitted
stat64_wrx 5438 top_int : 4-byte words received
305185229 bottom_int : 4-byte words received
stat64_ftx 55 top_int : Frames transmitted
77619371 bottom_int : Frames transmitted
stat64_frx 15 top_int : Frames received
751990230 bottom_int : Frames received
This then translates into ((27136*4294967295)+346392029)*4/(55*4294967295)+77619371 ~ 1973 bytes.
So as you can see it makes sense to take a look at the 64-bit counters. On the commandline you can also use the “-long” parameter so FOS does the calculation for you.
Hope this helps.
Regards,
Erwin
Hi Erwin! Two questions:
1) Why don’t u multiply 346392029 by 4 as well? This counter is for 4-byte words.
2) Why u multiply 55*4294967295 by 4? I think u shouldn’t as these values are for frames
Yury,
You are correct. I don;t know why I did write it that way as my (hds internal) post has the correct one. 🙂
I modified the formula and it should be OK now.
Thanx Erwin! Great post in the area of SAN audit
Thanks Erwin, a good read, as always. However, this is not the only problem. See DEFECT000491910. We suspect that we’ve hit this one recently.
Hello Alexei,
This may indeed be a problem. As always, maintaining code-levels can prevent these issues.
We’ve qualified 7.3.1a for a while (as of this writing) and this particular defect is closed with code-change on that level.
Thanks for your comments. Highly appreciate3d as always.
Regards,
Erwin.