Calculating link utilization

[redrattus]

Hi, I am newbie in sflow.

Currently, I am developing some sort of monitoring tool to get view of my network (i.e., openvswitches).

The problem I still encounter is that the link utilization which I calculate is over 100%.

Is it possible? If so, what does it mean?

The calculation for link utilization I used is as follow:

Assume that every 5 secs I receive counter samples.

Using input and output bytes information in the counter sample, I subtract the current bytes information from the previous one. Then multiply by 8 to translate to bits, then divide by 5 secs to get bps. After then I divide it by interface speed in counter sample.

[Peter Phaal]

This issue was discussed on the Open vSwitch mailing list. There is no well defined interface speed on a virtual switch interface, so calculating utilization doesn't make much sense.

http://www.mail-archive.com/dis...@openvswitch.org/msg04674.html

[rick jones]

On Jan 9, 2013, at 3:17 PM, redrattus <redr...@gmail.com> wrote:
> The calculation for link utilization I used is as follow:
> Assume that every 5 secs I receive counter samples.

Don't. You could, presumably be receiving the counter samples at an interval perhaps centered on every five seconds, but the nature of the beast is such that there can be non-trivial variation. ftp://ftp.netperf.org/high_freq_sflow/hf_sflow_counters.html . If you have trouble with the html version there should be a .pdf version there as well.

rick jones

[redrattus]

Yes, I knew the issue that you are mentioned.

So I use tc program to limit the bandwidth (e.g., 10Mbps) between two veth ports (switch1-veth1 ==10Mbps== switch2-veth1).

Then I explicitly divide the bytes count by 10 Mbps.

[rick jones]

On Jan 9, 2013, at 7:11 PM, redrattus <redr...@gmail.com> wrote:

> Yes, I knew the issue that you are mentioned.
>
> So I use tc program to limit the bandwidth (e.g., 10Mbps) between two veth ports (switch1-veth1 ==10Mbps== switch2-veth1).
> Then I explicitly divide the bytes count by 10 Mbps.

I don't see how the tc program will fix something inherent in the sFlow agent/specification. The issue isn't that the bandwidth through the port/whatnot varies or needs to be clipped, it is that the way the sFlow agent (possibly) sends the sFlow PDUs makes it *appear* as though the bandwidth varied, when it didn't. That was the whole pointe behind comparing what netperf was reporting for throughput vs what sFlow was reporting with its somewhat randomized counter sample sending rate.

rick

[Peter Phaal]

http://www.openflow.org/wk/index.php/Slicing

Looking at the charts in the above paper, it also looks like actual data rates vary around the nominal bandwidth configured with tc so you would expect to see utilization above 100% occasionally if you are dividing by the nominal bandwidth (it's not a hard upper limit like it would be with a physical interface).