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

[Sebastian Harl]

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.

Cheers,
Sebastian

> > [bug543631] http://bugs.debian.org/543631

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20100114/753efe40/attachment.pgp