Alex van den Bogaerdt ([EMAIL PROTECTED]) wrote on 2 July 2001 01:10: >> First, I don't see the need to force users to define RRAs. Why the >> hell can't we simple stash the data in there???? > >??? an RRA *is* where the data is stored.
I see this is a consequence of the design. The point is I don't understand why. >> Second, why is it mandatory to use a consolidation function in >> rrdfetch? Why can't we just get back the raw data? > >Because there is no raw data to begin with. This is by design. >You are not storing raw data, you are storing rates. You need >to understand what is happening when consolidation occurs to >appreciate the difference between AVERAGE and MAX for instance. I see the difference. These are extra facilities, no problem here. >> Third, I don't like the idea of alignment of the data to the >> predefined time steps. This should be optional. > >You have the option of using mySql or something similar. This >is the type of database you should use if you want to get out >what you put in. You also need to do maintenance on such a >database and you need to calculate each rate at graphing time. It's not a problem to calculate the rate at graphing time. >> In summary, I find the idea of rrdtool very good, [...] > >I'm sorry but you missed the whole idea behind RRDtool. Maybe. Or maybe there should be a third 'r' in the name? It seems it means round-robin database, not round-robin-rate database... RRDtool is announced as a round-robin framework for storing continuously acquired data, no matter what kind of it. It seemed to me that the averaging and other manipulation tools were pluses, not design premises. -- 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
