This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]