> > 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 hundredths? 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 the structures. 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.] --mark mills Xodiax Engineering -- 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
