Giese, Edgar wrote: >thanks for answer. I think I haven't understand it yet. > >I don't know if it is a COUNTER or a GAUGE (see data.txt). There it >says it is GAUGE, but I think it is a counter because it is the page >count of the printer. It is the value of printed pages since ever. > >I haven't found any value in the MIB for Printers, that represent >pages/second. Do you know any? > >So, I think, there is no solution?
Please keep discussion on-list unless specifically asked otherwise. Yes, your file says you've used gauge - you need to use counter. I would expect that all printers will have a total pages printed counter, few (if any) will have a resetting counter (pages since last read) or page rate. Once you start using a counter data type you will find things work fine. You can draw a graph of pages printed/time, and as I said in my previous reply, calculating a total is easy. If you are still unclear, let me try and elaborate. You are driving along a road, and the odometer on your car is counting up the miles (or kilometers). If you periodically record the miles driven and time, you can work out the average speed between those points. This is what the counter data type does - and was originally written to handle byte counts from routers. You printer will tell you how many pages it has printed since it was made, and this is analogous to the odometer in the car telling you how many miles it's driven since it was made. Once you have this information, it's easy to consolidate it to get a higher level overview. Eg, you probably aren't interested in seeing second by second how fast you are going in stop-start traffic - it's enough to know that it took you half an hour to cover 10 miles (so 20 miles per hour) so that next time you are in that situation, you can estimate out how much time to allow yourself for a future trip. Equally, for your printer, you aren't bothered about seeing it was going flat out for half a minute and then idle for the rest of the hour - it's sufficient to see that it's been doing (say) 10 pages/hour for your to estimate it's utilisation and running costs. If you want to know how many pages were actually printed in the last week, there are two ways of doing it. You can keep a record of the page counts at various times, and do a lookup to see how much it's changed. Or you can look at the average print rate over the last week, multiply by a week, and get the total (give or take some rounding errors). RRD will not do the first for you - it isn't what it's designed for. It will do the latter. So say you have an average print rate of 60/day over the last week, then the pages printed in a week is about 60*7 = 420 pages. So setup a new RRD using data type COUNTER. Create RRAs for whatever periods you are likely to want. As an example, I balance storage vs detail by keeping 5 minute data for 2 days, 1/2 hour data for 14 days (2 weeks), 2 hour data for 62 days (2 months), and 24 hour data for 730 days (2 years). Thus I can look back for 2 years, but not see data more detailed than "per day" - or I can see "per 5 minutes" for data from the last 2 days. There's nothing to stop you keeping 1 minute samples for 5 years - but it means more storage and more processing when you want to draw high level graphs. If you now draw a graph from "end-7d" to "end", then you can get the average print rate (AVERAGE function), and you can get a total (TOTAL function). Also, looking back at your data. If you will want to see the maximum rate, then you MUST store an RRA for MAXIMUM, and similarly for minimum. If you only store an average, then you cannot derive a maximum - say your print rate averaged 100/day - that only tells you that during the day there were 100 prints. You have no way of knowing if they were done at about 4.2 prints per hour all day, or if the machine ran flat out for a few minutes and sat idle for the rest of the day. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ rrd-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
