Alex van den Bogaerdt wrote: > On Mon, Feb 25, 2008 at 07:05:06AM -0800, Thorsten von Eicken wrote: >> Define "more data". Getting 599 data points (last data point missing) is >> more data in my book than getting 22 data points that happen to cover >> the last 20 seconds. > > You aren't presented points. You are presented time and value, > combined.
Of course these are data points! A data point can cover a time interval. That doesn't make it not a data point. > You are asking for data that is not yet there. You get as little of > it as possible. And if this means selecting the RRA at 4520 seconds > per bucket, then so be it. Suppose you're a sysadmin or a network admin. You're looking at the last day graph of a device. Data for an hour because of a problem. What do you expect to see? A graph that ends with the last data point (i.e. an hour ago) leading you to believe that everything is fine unless you carefully look at the X axis? Or a graph that ends "now" and shows the data gap at the end of the graph? I have not seen any serious network monitoring tool that shows the former, and I would refuse to use one, actually. > It's clear that I think the decision to alter best-match is wrong. > In my experience, when something is fixed in the wrong place this > will eventually lead to a long series of related problems. I've been seeing the resolution issues I described for many years. But in the past I used RRAs whose steps were closer to multiples of one-another causing the low-res graphs to clear as soon as I'd refresh. Also, I never saw something as dramatic as a 600 pixel graph with 22 stairsteps. So I always shrugged my shoulders and ignored the problem that was clearly there. It's only now that I could fairly easily grab a reproducible case and track the issue down in the source code. Thorsten _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
