[rrd-users] [rrd] Can't I turn off data smoothing for GAUGE?

Philip Peake philip at vogon.net
Thu Aug 19 17:58:49 CEST 2010


 On 8/19/2010 8:14 AM, Marc MERLIN wrote:
> On Thu, Aug 19, 2010 at 07:52:06AM -0700, Philip Peake wrote:
>>  Yes ... I am actually measuring two parameters.
>> One of them has fairly high numbers (in the 100's), the interpolation
>> (or whatever you want to call it) is ok there. The actual number
>> displayed is not too important as long as its something like right.
>>
>> The second set of samples are more like:
>>
>>     0 0 0 0 0 0 1 0 0 0 1 1 0 0 2 0 5 0 0 0 0 3 0 0 1 0 0 0 0 0 1
>>
>> They are integer values. Displaying them as (for example) 0.666732134 is
>> meaningless.
> So if you don't have a workaround, at this point the fix is to give Tobias a
> patch that doesn't break the common case.
>
> Marc
I *think* that's fairly easy. But I only spent about 5 minutes last
night looking at the source.

I would start by adding a new command line option
(/--dont_screw_with_gauge_data/ or similar), and change this line:

     rate = pdp_new[ds_idx] / interval;

To look more like:

    if (dont_screw_with_gauge_data) {
            rate = pgp_new[ds_idx];
    } else {
       rate = pdp_new[ds_idx] / interval;
    }

Now your case, as I understand it (I didn't go back and look in the
archives to fully understand what you wanted to do) is to store a set of
bits. If that's true, that is a bit more work because it looks (in my 5
minutes of digging) that the values are stored as floating point values,
not integer, so that would require a lot more digging to see how to do
that. Its probably a quite pervasive change ....

Rather than storing as a bit pattern, assuming you can avoid
interpolation (with something like the above, or as Simon suggested,
forcing the time to boundaries) you can use powers of ten:

00001 -> 10
00010 -> 100
00100 -> 1000
01000 -> 10000
etc,

adding up the total and storing that. floating point conversion is not
going to lose that much precision.
To recover your bit pattern you start with the highest "bit" value, see
if division by that is > 1 (so bit is present), subtract that power of
ten, repeat for the next lower power of ten etc.

I *think* this would work ... you would need to play around with it ...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/rrd-users/attachments/20100819/e1941510/attachment.htm 


More information about the rrd-users mailing list