[rrd-developers] Re: If I could save time as a double ...
plonka at doit.wisc.edu
Tue Nov 20 00:34:28 MET 2001
On Tue, Nov 20, 2001 at 12:03:56AM +0100, Alex van den Bogaerdt wrote:
> Dave Plonka wrote:
> welcome back...
> > [...]
> > I'm exploring the possibility of using rrdtool to do this.
> > Some options I have are:
> > 0) Use rrdtool unmodified, but use it in a kludged way by lying to it
> > about the "current" time on updates.
> Did this; while you will be able to get it working it isn't nice
> to work with. OTOH it's probably less effort than changing the
> code. You're likely to encounter problems and other stuff that
> you didn't knew existed doing so.
My intuition says the same... but I was probably dumb enough to have
tried it anyway, so I'm glad you saved me some time there.
> > 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.
Agreed, an integer fraction might be best - at least for the format in
the data file. Still I'd be tempted to use a double at run-time, since
it's easy to do modf(3) and doesn't require bigint arithmetic.
BTW, as a point of comparison, Mark Fullmer's flow-tools flow-capture
utility has you specify the number of "rotations" per day (rather than
the step value in seconds), which avoids having to store the
floating-point value. Since RRD is already good at storing
floating-point values I'm not sure that's a concern, but it alleviates
the rounding error problem, and the repeating decimal problem. (Since
it's per-day, it also zeroes the value it at the start of the day UTC
so your times don't drift over a series of days.)
I just patched flow-capture to work with times as doubles for the
purpose of that interval calculation:
That was a lot less work, though, than it will be for rrdtool.
Anyway, specifying the number of rotations per-day might be a viable
alternative to a fractional part of a step value. It would would
require another option on "rrdtool create", and only makes sense for
intervals less than one-day, although that's 99% of rrdtool usage
> > Is it possible to maintain binary compatibility for the data file
> > (finding some place to store four more bytes for the step) or would
> > this require a new version of the binary file format, and very
> > many source code changes including dump and restore?
> Changing the source would be necessary just to process the fractions
> so why not change the .rrd file format too. RRDtool could continue
> to work with old format files or it could convert them on the fly.
> Of course, when it finds a new version file it stays that way.
Thanks for your input...
Other thoughts welcome too!
plonka at doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI
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