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 -- [EMAIL PROTECTED] http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/rrd-developers WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
