[rrd-developers] Re: If I could save time as a double ...
mark at xodiax.com
Tue Nov 20 00:22:00 MET 2001
> > 1) Modify rrdtool to allow a double as the step value.
> I'd opt for an integer fraction. A short brainstorm session with
> myself alone showed that IMHO it is much cleaner. Another 32-bit
> value gives the most digits per byte *and* gives the best precision
> so that's probably what would be best. Using an integer in stead of
> a double will probably cause less rounding errors, at least that's
> my gut feeling.
[I posted this once but the list carped at me for over-quoting so it
languishes somewhere in the listmanager...]
Would it be easier to patch it to treat the step as milli-seconds? or
It has been a while since I dug through that part of the code but it
seems easier to "move the fixed point" than to change to a double and
muck with floating point math all through the system. Part of the speed
of RRDTool is using integer math to naturally give you your offsets in
Admittedly, milliseconds will only allow .125 or 1/8th second
poewr-of-two fractions at best but it might be a lot easier to add (*
1000) most of the places "step" is than sort out rounding everywhere.
[Having looked at the source you could probably use the high bit in step
as a flag and not tinker with the file format at all. Anyone needing an
interval that big in rrdtool is crazy anyway. =) Of course you get stuck
with "if"s or bit-twidling as a drawback.
Alternately, you would have to bump the version and reject/upgrade older
files. If you don't reject on version you wind up with the same issue as
the flag trick and have to wrap everything in "if"s to deal with
versions. Still, it is better than doubles and messing with the integer
rounding maths logic.]
Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
More information about the rrd-developers