Port counters may be flawed.

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.

  1. Clear these counters with the “statsclear” command and looks at the values before they wrap. (On busy systems this can be pretty quick though.)
  2. 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

Print Friendly, PDF & Email

Subscribe to our newsletter to receive updates on products, services and general information around Linux, Storage and Cybersecurity.

The Cybersecurity option is an OPT-OUT selection due to the importance of the category. Modify your choice if needed.

Select list(s):

5 responses on “Port counters may be flawed.

  1. Yury Yavorsky

    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

    1. Erwin van Londen

      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.

  2. AlexeiStepanov

    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.

    1. Erwin van Londen

      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.