This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/11308] aggregate operations for @variance, @skew, @kurtosis
- From: "fche at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Tue, 28 Jun 2016 15:13:44 +0000
- Subject: [Bug runtime/11308] aggregate operations for @variance, @skew, @kurtosis
- Auto-submitted: auto-generated
- References: <bug-11308-6586 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=11308
--- Comment #5 from Frank Ch. Eigler <fche at redhat dot com> ---
Excellent progress!
> This gives somewhat reasonable results for a "few" "small" integers with
> normal distribution, but almost any other set of values makes it behave
> crazily because of the integer arithmetic being used for the dividing.
I suspect the loss of precision is occurring in the per-cpu sd->variance =
stp_div64() ... code rather than the cross-cpu agg->variance one. Your test
case (probe oneshot) runs only on one CPU, so a lot of the cross-cpu terms (S1)
should be zero.
> At the first glance, the floating point arithmetic inside the linux kernel
> doesn't look like something usual or straightforward. But an attempt to
> implement it might be an interesting one. Not sure about this though.
We'll eventually get -some- FP capabilities for stap code, but let's see how
much farther we can get without.
If you have any more time/interest in this problem, I'd suggest investigating
whether we could track the sd->avg / sd->_M2 / sd->variance values in a scaled
form. We continuously track max/min, so have a good idea about the dynamic
range of the <<<'d values. The code could track a "shift" parameter that
scales those numbers (via << shift) during the online update phase so as to
preserve as much precision as possible.
Another thing we should consider afterwards is bug #10234. For a stap script
not interested in @variance, this code should not be run at all.
--
You are receiving this mail because:
You are the assignee for the bug.