[nm-wg] Specifying units

adrian cockcroft adrian.cockcroft at gmail.com
Mon Sep 26 15:15:59 CDT 2005


Utilization should be defined as busy time/total time, its dimensionless or
percent. Doesn't matter if its network or CPU or disk, thats the standard
definition of utilization.

Network capacity depends how you look at it, the wire speed gives you a bps
(100Mbit/s, 1Gbit/s) that is easy to obtain and an absolute limit, but not
useful for calculating utilization because of protocol overhead.

Throughput in octets/s is reported by most NICs but the maximum possible
octets/s does not equal the bps of the wire, due to inter packet gaps and
framing of the low level prototcol. The maximum also depends upon average
packet size.

So since the two measures are of different things, it does make sense that
they are in different units. That way someone who is about to divide one
into the other might be prompted to ask why they are different units and
become more enlightened about the meaning.

It would be nice if there was a common standard way to calculate network
Utilization (%busy) but I haven't seen it. I came up with a calculation that
tried to include framing and gaps once. I think Orca uses it. (
www.orcaware.com <http://www.orcaware.com>).

Adrian





On 9/26/05, Loukik Kudarimoti <Loukik.Kudarimoti at dante.org.uk> wrote:
>
> Hello Gang,
>
> It has come to our notice that the messages in v2 responses do not
> specify units while giving back measurement data (ex: Bandwidth
> Utilization and Capacity). Specifying such units is necessary and
> messages should be enhanced to support this.
>
> Also, there is scope for optimization in such specification. For
> example, while returning back data
>
> instead of
>
> <perfsonar:datum timeValue="1127183580" value="7.620117028888889E7"
> units ="bps"/>
> <perfsonar:datum timeValue="1127183640" value="1.4989345286805557E7"
> units ="bps"/>
> <perfsonar:datum timeValue="1127183700" value="1.50811390446627E7" units
> ="bps"/>
>
> we could specify it just once..maybe like this:
>
> <perfsonar:data dataUnits="bps">
> <perfsonar:datum timeValue="1127183580" value="7.620117028888889E7"/>
> <perfsonar:datum timeValue="1127183640" value="1.4989345286805557E7"/>
> <perfsonar:datum timeValue="1127183700" value="1.50811390446627E7"/>
> </perfsonar:data>
>
> or like this:
>
> <perfsonar:data>
> <perfsonar:units dataUnits="bps"/>
> <perfsonar:datum timeValue="1127183580" value="7.620117028888889E7"/>
> <perfsonar:datum timeValue="1127183640" value="1.4989345286805557E7"/>
> <perfsonar:datum timeValue="1127183700" value="1.50811390446627E7"/>
> </perfsonar:data>
>
> or something else...
>
> The second comment is: Choice of units.
>
> After a chat with Jeff on this, I can list out two options
>
> Jeff suggested that: Service uses the units that the data is already in
> (for ex. in rrd tool, data is in octets per second. Hence service
> continues to provide data in octets per second) and continues to return
> data in the same units. However, the units in use should be clearly
> specified using any of the above suitable methods.
>
> An option that I would like to propose is usage of units used in common
> practice. For example, bandwidth, as known to me, is more commonly
> expressed in bps (and their factors). A service should hence
> *reasonably* strive to use the units that are in common practice. Either
> way, specification of units using any of the suitable methods mentioned
> previously is absolutely necessary.
>
> However, it can be remarked that 'bps' is not necessarily common.
> Netflow measurements might prefer to use something else which are in
> common practice in the netflow domain. In such cases, specification of
> units should suffice.
>
> Nevertheless, if a service returns capacity and utilization in the same
> message, it would be nice to have them both in the same units (unlike
> the current case with Perfsonar prototype where capacity is bps and
> utilization is octets per second)
>
> Question here is: Which option is ideal? Should we provide capacity and
> utilization in the same units in our prototype?
>
> Loukik.
>
>
>
>
>
>
>
> --
> ______________________________________________________________________
>
> Loukik Kudarimoti
> Network Engineer
>
> DANTE - www.dante.net <http://www.dante.net>
>
> Tel: +44 (0)1223 371 300
> Fax: +44 (0)1223 371 371
> Email: loukik.kudarimoti at dante.org.uk
>
> City House, 126-130 Hills Road
> Cambridge CB2 1PQ
> UK
> _____________________________________________________________________
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nm-wg/attachments/20050926/e7c06d4f/attachment.html 


More information about the nm-wg mailing list