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 Tel: +44 (0)1223 371 300 Fax: +44 (0)1223 371 371 Email: loukik.kudarimoti@dante.org.uk City House, 126-130 Hills Road Cambridge CB2 1PQ UK _____________________________________________________________________
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@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@dante.org.uk
City House, 126-130 Hills Road Cambridge CB2 1PQ UK _____________________________________________________________________
adrian cockcroft wrote:
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.
You are right that this is somewhat confusing. We are using the term utilization as defined by the nmwg Hierarchy document: http://www.gridforum.org/documents/GFD.23.pdf See section 7.2. Granted, this would probably be better named "utilized". In fact, from looking at several other documents (and even other places in this document) I would actually expect this to be called: interface.bandwidth.utilized jeff
Loukik Kudarimoti 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...
I think units are part of the base "datum" type. So to get your optimization without fiddling with schemas, you could use: <perfsonar:datum timeValue="1127183580" value="7.620117028888889E7" units="bps"/> <perfsonar:datum timeValue="1127183640" value="1.4989345286805557E7"/> <perfsonar:datum timeValue="1127183700" value="1.50811390446627E7"/> By the way, if this is really what your data looks like, I would roughly swap the resolution of the value and the timestamp. -Dan
participants (4)
-
adrian cockcroft -
Dan Gunter -
Jeff W. Boote -
Loukik Kudarimoti