Re: Are measurements cumulative?

Hello Mark,

many thanks for the quick and detailed answer.
Two question came up while reading your answer (See below, sorry).

Cheers

-Frank

On Fri, 2012-02-17 at 16:10 +0100, Mark Seger wrote:
>
>

>
>         How does the tool calculate
>
>         -a- quantities (like number of slabs, memory allocated,
>         queuelength,...)
>
> these are simply instantaneous values as reported in /proc/xxx
>
Okay, this means that one might miss peak values upon increasing the
measurement time.

>         -b- utilisation (CPU used%,...)
>
>
> all cpu times reported in /proc/stat are in jiffies, so I just look at
> the change between to samples and add up the user, system and other
> times ignoring iowait since that's not real cpu.  this then gives me
> the total number of jiffies in the interval.  now it's simply a matter
> of something like
>
>
> user/total*100 to tell me the % time spend in user time
>
>
> some tools actually report based on a single core and so a cpu bound 8
> core system would be reported as 800% but collectl reports 100%
>
Is the disk utilisation also based on jiffles?

>         -c- rates (disks read/write, iops,...)
>
>
> that's simply the different between start/finish divided by seconds.
>  if you include -on, it divides by 1 to give absolute numbers
>
>         when using different sampling intervals (-i ...)?
>
>
> numbers should all be the same unless -on specified
>
>         For rates it seems obvious(?) to divide the difference of
>         counter values
>         at the end and and the start by the sampling time.
>
>
> correct
>
>         Could someone explain what is the effect on choosing longer
>         sampling
>         intervals and how 'averaging' is done and which meas are
>         considered in
>         the calculation?
>
>
> the only different in using longer sampling intervals is loss of
> accuracy.  my favorite example is if you have a 30 second spike in the
> network and are only sampling every couple of minutes, you'll see an
> elevation but never know you were saturated for 1/2 minute.  even at
> 10 seconds you'll miss shorter spiked, but 10 seconds has shown to be
> a good compromise, though some user choose 5 or even 1 second.
Just for interest would it make sense that the tool would have some
'internal' hidden counters to make some maybe configurable number of
'hidden' measurements and sum values for each counter in these counters
to take the average in the end?
Maybe this is dump, cause one could choose a smaller measurement
interval from the start that would lead to the same computational
(concerning CPU and memory) overhead, but it would help to get more
'accurate' meas even for bigger interval with lower amount of
performance measurement data(?).

>
> hope this helps
>
Yes, very much. Many thanks!

Cheers

-Frank

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

Kennen Sie schon unsere app? http://www.fz-juelich.de/app

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/