On Thu, Dec 09, 2004 at 01:30:37PM +0100, Georges Toth wrote: > > Would you have set a sane maximum rate, as instructed by the documentation, > > this rate would have been ignored and you'd have ended up with unknown > > data. Since you really don't know the rate before and after the reset, > > that's not unreasonable. > > hmm i understand. > the problem is i don't know the maximum. > but i guess i could set one which is far too high but still below what > rrdtool > calculated.... :-)
Often finding a maximum rate is difficult but indeed, as you write, it is possible to find a rate that is certainly too much. Please understand that this procedure is only a workaround, not a real fix. > > Only if you're willing to ignore "This way you have the most accurate > > results". > > what is so different from counter and derive then ? That's not relevant. What is relevant is that I described a way to really deal with the reset; in other words I described a way to tell RRDtool what is happening. If you use the DERIVE_with_minimum_rate_zero method, you are telling RRDtool to ignore the updates around the reset. This results in a loss of information (a couple of updates will result in unknown data). If you use the tripple_update method, you are telling RRDtool what the rate was just before the reset, and when the reset happened. This way, RRDtool has no unknown data hence it has more reliable data. You will still loose some information, but this loss is limited as it is only the amount of data between the last update and the reset. This is one second, if you follow my suggestion. > > "rrdtool tune" can be used to alter the data source type and to change > > the minimum allowed rate. > > i tried rrdtool tune to change the dst to derive. a minimum was already set. If you change the DS_type from counter to derive, nothing bad should happen to your data. (This is NOT a warranty!) This statement only holds when you are willing to ignore data around a counter wrap or a reset, and when you also implement the minimum allowed rate of zero. > if i graph a month view, i only see the end of the month, with those far too > high numbers. > so i guess the changed dst will only make a difference by the next end of the > month, when those too high values won't be added to the db but instead, > "unknown". is that right? I think you are looking at data that's already in the RRD. Changing the DS_type will only influence data that is collected after this change. > if so, is it possible to change those some values around last endofmonth, to > unknown ? Yes. Option 1: - dump the database (rrdtool dump) - edit the xml file - restore the database (rrdtool restore) This modifies the available data. Option 2: - read the tutorial - implement the "pretend weird data isn't there" workaround This modifies the representation of the available data. HTH Alex -- You want an answer? You'd better follow the following guidelines! Linesize well below 80 chars. Reply to the list, not to me. Trim irrelevant lines. Reply _below_ the relevant lines, not on top. -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/rrd-users WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
