[rrd-developers] Re: If I could save time as a double ...

[Dave Plonka]

Hi Alex,

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:

   http://net.doit.wisc.edu/~plonka/flow-tools/

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
anyway.

> >    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!

Dave

-- 
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
Archive     http://www.ee.ethz.ch/~slist/rrd-developers
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi