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
signature.asc
Description: Digital signature
