Re: statistics with intermediate results

[James Dickens <jamesd dot wi at gmail dot com>]

On 1/11/06, Martin Peschke <mp3@de.ibm.com> wrote:
> Hi,
>
> another question of mine:
>
> If I want to provide latencies then I need to measure two times,
> send time and receive time. I can calculate a latency
> when I know both times, which requires the first time to be
> kept somewhere until I have measured the second time.
>

and really you don't need to keep all the results, basicly you could
just store min, max, and mean or medium and get the information you
would need for most tasks.


> The problem is where to put the first timestamp. It would
> be per request. But when I use dynamic instrumentation, e.g.
> systemtap, then I can't put some spare bytes in a
> per request data structure to store intermediate results.
>
> I guess, one could report all events, like send time, receive
> time and so on, through systemtap and defer all processing to
> a user land script. That's the Linux Kernel Event Trace Tool
> approach:

You can look at dtrace as an example it has agreations that store
events like this and give the ability to print them. you can also
quanitize the results as well.



> http://sourceware.org/ml/systemtap/2005-q4/msg00458.html
>
>  From a performance point of view, I am not sure it is the
> fastet way of getting latencies, because it involves huge
> amounts of data being generated by probes and being
> reported through relayfs, while we can't use the benefits
> of immediate data reduction as provided systemtap's statistics.
>
Agregations are what is needed, because you really don't need to store
all the data, just the best, worst and average cases.

> I am wondering whether dynamic instrumentation is the answer
> to this kind of measurement requirements.
>
> Thanks in advance for your thoughts.
>
> Martin
>