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

[Sebastian Harl]

Hi Tobi,

On Thu, Jan 14, 2010 at 02:20:05PM +0100, Tobias Oetiker wrote:
> Today Sebastian Harl wrote:
> > 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.
[...]
> > > > 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.
[...]
> > > 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 ...

Yep, I was rather thinking about storing the values itself (currently
stored as double). Anyway ... thinking about that again, a double should
still be sufficient for that.

Anyway ... 30 characters are not sufficient for (IEEE 754) 'long
double's (128 bits, a.k.a. quadruples), which use a 15 bit exponent,
i.e., up to 5 decimal digits plus sign, and 113 bit precision [*], i.e.,
up to 35 decimal digits, and the sign of the number itself. So, in E
notation, we'd need 43 characters in total. I'm not sure if it's safe to
decrease the precision -- on the one hand, we'll cast to double anyway
later on but, on the other hand, the least significant bits will, in
some (most?) cases, store the relevant information that's used when
diff'ing values. What do others think about that?

Cheers,
Sebastian

[*] one bit is stored implicitly somehow ...

-- 
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/1ee4d8e2/attachment.pgp