This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
statistics with intermediate results
- From: Martin Peschke <mp3 at de dot ibm dot com>
- To: systemtap at sources dot redhat dot com
- Date: Wed, 11 Jan 2006 15:47:56 +0100
- Subject: statistics with intermediate results
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.
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:
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.
I am wondering whether dynamic instrumentation is the answer
to this kind of measurement requirements.
Thanks in advance for your thoughts.
Martin