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

[Philip Peake]

 Here is what I don't understand:

    http://oss.oetiker.ch/rrdtool/tut/rrd-beginners.en.html
    /GAUGE does not save the rate of change. It saves the actual value
    itself. *There are no divisions or calculations*.
    /

Looking at the source:

                case DST_GAUGE:
                    old_locale = setlocale(LC_NUMERIC, "C");
                    errno = 0;
                    pdp_new[ds_idx] =
                        strtod(updvals[ds_idx + 1], &endptr) * interval;
                    if (errno) {
                        rrd_set_error("converting '%s' to float: %s",
                                      updvals[ds_idx + 1],
    rrd_strerror(errno));
                        return -1;
                    };
                    setlocale(LC_NUMERIC, old_locale);
                    if (endptr[0] != '\0') {
                        rrd_set_error
                            ("conversion of '%s' to float not complete:
    tail '%s'",
                             updvals[ds_idx + 1], endptr);
                        return -1;
                    }
                    *rate = pdp_new[ds_idx] / interval;*
                    break;

If this line is removed, it will behave as documented.
I can not really see any point in this, a gauge is a gauge, its not a rate.

----------------


On 8/18/2010 10:41 PM, Tobias Oetiker wrote:
> Hi Marc,
>
> Yesterday Marc MERLIN wrote:
>
>> On Wed, Aug 18, 2010 at 09:38:20AM -0700, Marc MERLIN wrote:
>>>> as for storing arbitrary binary data as time series in rrdtool, it
>>>> is all a matter of coming up with a sensible configuration model
>>>> and implementation strategy for makeing this work ... if you want
>>>> to spend your time on this, I'll be glad to review your plan and
>>>> code. And I will also merge your patches if we can agreee on things
>>>> ...
>>>>
>>>> but as you dive into the code you will seee that your project would
>>>> require rather fundamental 'work'
>>> I had a simple thought this morning: just ignore any value that's been
>>> interpolated by cacti and throw it away.
>>> An easy way to detect one is that it's very unlikely that it'll be an
>>> integer, so instead of
>> Going back to your point, while I don't need this myself anymore (although I
>> just see another message apparently asking for the same thing), how about
>> this:
>> - make a new DATA type that is similar to GAUGE without smoothing
> yes the separate datatype approach would be 'the thing todo' note
> though rrdtool is not 'smoothing' anything, what happens, is that
> rrdtool re-samples your input at the configured step frequency (so
> if you put in your data at exactly the step-points, no re-sampling
> will happen) for thing you do not need to change rrdtool, just fix
> your input. If you do want to be able to have some of the data
> re-sampled and some not inside the same rrd, code changes would be
> required, as you would have to adopt some sort of 'keep the last
> update that has arrived within the sampling interval and mark it
> valid for the whole interval'- aproach.
>
> At the next level you might also want to add a special RRA type
> which does not do consolidation ... maybe the LAST type might
> double as that ...
>
> And thirdly you would have to change storage type of data inside
> rrdtool to 'long long (64bit integer)'  from the normal double
> since double would prevent your bitfield input from working when
> you use all the bits ...
>
> Then the code in rrd_graph would have to be adapted to unserstand
> the new DS and RRA types
>
> ....
>
>> or
>> - add a rrdtool create flag for GAUGE where it's marked as no smoothing
>>
>> I haven't looked at the code and can't comment on how difficult either is,
>> but I can think of several legitate uses for GAUGE where smoothing would not
>> be ok (not counting my bitfield thing, which is admittedly mabye a bit
>> beyond what rrdtool fields were originally meant for, even if it happens to
>> work great ;) ).
> as I said ... I'll be glad to review any patches ...
>
> cheers
> tobi
>
>> Marc
>>

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