Today Philip Peake wrote: > On 8/19/2010 8:15 AM, Tobias Oetiker wrote: > > Philip, > > > > Today Philip Peake wrote: > > > >> Yes ... I am actually measuring two parameters. > >> One of them has fairly high numbers (in the 100's), the interpolation > >> (or whatever you want to call it) is ok there. The actual number > >> displayed is not too important as long as its something like right. > >> > >> The second set of samples are more like: > >> > >> 0 0 0 0 0 0 1 0 0 0 1 1 0 0 2 0 5 0 0 0 0 3 0 0 1 0 0 0 0 0 1 > >> > >> They are integer values. Displaying them as (for example) 0.666732134 is > >> meaningless. > > please elaborate ... time based integer data ? never seen it ... > > > > :-) > > Ok ... lets try. > > This is a queue. > In the trivial case, its empty. > In other cases there are an integer number of items in the queue > (partial items don't exist).
yes > > Obviously, the number of items in the queue varies with time. > Because of the short timescales involved in processing these items, any > reading of the number of items in the queue is only a snapshot. Fraction > of a second earlier or later and the number could be significantly > different. But it will always integer. > > The data is not time based, its based upon request rates and processing > rates. It will change with time but is essentially not itself directly > related to time. > > Does that make sense? ok ... except that if you put it like this, why do you even bother collecting this information when the number of items in the queue is random anyway ? I suspect it is not random but there are times when the queue tends to be fuller and other times when it tends to be empty, so by sampling the queue size you can get some information to the number of items one might expect to find. If you were looking for exact date you would have to sample with twice the rate of change of items in the queue to get sensible results ... of you could count items entering and leaving the queue separately and come up with some very good data ... but I disgress. back to rrdtool ... it will store the 'average' number of items to be found in 'one step' so while every single measurement gives you a integer number of elements, on average you will end up with 3.2 elements in the queue over a 5 minute periode ... and just to note, rrdtool can deal fine with you sampling every few seconds and handing rrdtool the data you found it will integrate and come up with the average number of items in the queue over 1 step periode even when the periode is 10 minutes ... hth tobi > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch [email protected] ++41 62 775 9902 / sb: -9900 _______________________________________________ rrd-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
