[rrd-developers] Bug#543631: Bug#543631: rrdupdate does not support floating point values with DERIVE, COUNTER

[Tobias Oetiker]

Hi Sebastian,

Today Sebastian Harl wrote:

> Hi,
>
> On Thu, Jan 14, 2010 at 08:12:38AM +0100, Tobias Oetiker wrote:
> > Dec 28 Sebastian Harl wrote:
> > > (This is a follow-up to Debian [bug543631].)
> > >
> > > On Wed, Aug 26, 2009 at 08:00:22AM +0000, Florian Weimer wrote:
> > > > Floating point values are supported with GAUGE.  This suprising
> > > > behavior is not clearly documented, as far as I can tell.  I don't
> > > > think there are architectural reasons for this behavior.
> > >
> > > [side note: "this surprising behavior" refers to the subject of the
> > > E-mail, i.e. "rrdupdate does not support floating point values with
> > > DERIVE, COUNTER" ;-)]
> > >
> > > I'm not entirely sure about any reasons for that either. COUNTER and
> > > DERIVE values are stored as a rate (i.e., a double) as well anyway. To
> > > be able to calculate the rate, the last value is stored as well. This is
> > > done using a string, though, so it does not impose any limitations
> > > either.
> > >
> > > With this E-mail, I'm forwarding the issue upstream, hoping for an
> > > explanation (or request for patches ;-)).
> >
> > the reason for this is that rrdtool does the integer math for
> > building the difference between two counter values 'by hand' with
> > the advantage of being able to handle really long counters ...
> >
> > OTOH with long long being available across the board, this might be
> > a bit of a anachronism ...
>
> So, "really long counters" is supposed to be 64bit integers, right? I
> presume that using 'long long' should not be a problem on most systems
> that run RRDtool, but please (anybody) correct me if I'm wrong.
>
> Anyway, if this really happens to be a problem, we could still fall back
> (at compile time) to a different implementation (possibly even using
> some external library -- I expect this to happen on less-powerful
> hardware mostly; using some lib that includes optimized code for such
> architectures might be an additional benefit).
>
> > not quite sure though, what happens when
> > you diff two doubles realy close to 2^64 ... does this stay
> > accurate enough ? I guess a little magic would still be needed
> > there ... care to investigate ?
>
> Hrm ? this will probably be an issue, since the diff is fairly small
> (usually) and the precision of 'double's is limited to 53 bits (IEEE
> 754). 'long double' might be a solution to that, but I'd expect quite a
> few problems on different architectures. Also, this would probably
> require modifications to the on-disk format :-/
>
> Not sure, if there is a (backward-compatible) way to address this issue.
> Any comments and suggestions would be welcome.

the on-disk format for storing tha last 'value' is an ascii string
(30 char) which would be enough for 99 bits or so ...

cheers
tobi


-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900