My chance to stick my oar in :) > > > there was never a generic patch with a sensible interface. If you > > > are interested in the second axis thing, please, before you start > > > coding, come up with a configuration method and discuss it on the > > > developers list ... > > > > I'll have to think more about this ... > > The grid will probably be the most difficult problem to solve. > > exactly where I always end up when I start thinking about it :-) >
I would love to have an interface to RRDTool to allow the specifying of multiple Y-Axis - then I'd use it in routers2 for userdefined combination graphs. I can well appreciate the problem of the grid as just calling the function multiple times will not result in matching grids! Compared to this, working out some syntax for specifying the axis to rrdgraph is almost trival :( No point in going into detail about the coding issues in this forum, but I can see why it's not been done, that's why I've never asked Tobi for it myself. As far as the precision discussion goes, it's a tradeoff. With the RRDTool method, we get auto-normalisation, which saves huge amounts of work and greatly simplifies things - but means that storing integers is not possible. If I want to disable this (which is the case for one application) then I pre-normalise the timestamp before I store the data, or else I use a different storage method. If you want wildly varying sample frequencies, then RRDTool is not the way to go as it is tuned for regular polls. So, the way to approximate what (I think) Karl wants, is to pre-normalise the timestamp before you call RRDTool to store the data, and then set the 'integer' option for display. You may not be able to use MRTG for data collection, though, as it takes care of the timestamp itself. Steve _______________________________________________ rrd-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
