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]

Re: Measure the Accept Queueing Time


Hi, Ken -

On Fri, Feb 17, 2006 at 08:22:35AM -0000, Ken Robson wrote:

> [...]  There have been some hints (unless I missed something more
> concrete) about aggregations. Statistical functions that seem useful
> that do not aggregate well seem to be mode, median and standard
> deviation - each of these would seem to require that you retain the
> entire data set [...]

I am not a numerical methods guy, but I gather that at least some of
these functions *can* be aggregated incrementally, approximately if
unavoidable.  There exist incremental (or "streaming" or "on-line")
algorithms for calculation of variation, standard deviation, and
median functions, that do not require storage of the whole data set.
This paper seems to be a nice introduction:
http://citeseer.ist.psu.edu/muthukrishnan03data.html

> What built-in data 'visualisation' functions do people envisage and
> how efficient (in terms of shipping data to user space or retaining
> data in the kernel) do people think they will be [...]

As much data reduction (filtering, aggregation) as possible (small
cost in time and space) should likely be done in kernel space.  As
fast as bulk kernel-to-user data transport may be, it may still cost
orders of magnitude more to encode/buffer/context-switch/decode/filter
than to do the computation right at the point of origin.

As far as graphical visualization goes, that would need to go into
user space, interfacing with plotting/waveform/trace browsing tools,
but I don't think that's what you meant.

- FChE


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