Given the existing established behaviour, I think that it is preferable not to change the current behaviour for the sake of backwards compatibility, even though I still think the current is not quite 'right'. As long as it is clearly documented people can take it into account.
HW is technically better but a lot of additional work to implement and there is a rather steep learning curve to get your head around it all. So having the PREDICT option does give an easier alternative, and one that works straight away. Percentile calculations -- which we already have via the PERCENT VDEF operation -- are progressively more inaccurate the larger the granularity of the underlying RRA. Explaining this ended up on the Routers2 FAQ it was asked so often. Although you can use step= in the DEF to pull out a better resolution RRA this is only an option if one actually exists for the graph time window. Else you get the same problems. However, even with this caveat, people do love having them... so maybe a version of PERCENT to work on CDEFs with a PREDICT-style window would be useful for some people. Maybe syntax like s1,s2...sn,n,x,p,PREDICTPCT would work? You'd only get bad performance hits if people had VERY long high-resolution RRAs... The ROR/ROL comment was me veering off at a tangent into something unrelated. ROR is a stack-rotate function similar to EXCH. EG: 1,2,3,ROR ==> 3,1,2. I've had a couple of cases where I could only manage the RPN equation I was after by either using the nonexistant ROR or by using an additional CDEF. These two would be very quick and easy to implement I think. Steve Steve Shipway University of Auckland ITS UNIX Systems Design Lead s.ship...@auckland.ac.nz Ph: +64 9 373 7599 ext 86487 _______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
