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 t...@oetiker.ch ++41 62 775 9902 / sb: -9900 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
