[rrd-users] Re: icmp measurements with rrd?

[BAARDA, Don]

G'day again,

> -----Original Message-----
> From:	m.vernimmen at chello.nl [SMTP:m.vernimmen at chello.nl]
> Sent:	Thursday, November 02, 2000 1:28 AM
> To:	BAARDA, Don
> Cc:	rrd-users at list.ee.ethz.ch
> Subject:	Re: RE: [rrd-users] icmp measurements with rrd?
> 
> > Resampling is not a scary thing that needs to be worked around. All it
> does
> > is adjust input samples to fixed interval times. If you know the sample
> > values at the exact times, entering them at those times will avoid
> > resampling. If you don't know the true sample values at the exact times,
> > then you probably really want resampling, despite any uneasiness you
> feel
> > about it :-)
> 
> I know that, but like I stated it's impossible to enter the values at the
> moment they ocurred, because they are known only at a variable time after
> the moment the value ocurred.
> But I'll take this as a "no it's not possible".
> 
	You don't have to enter the values at the moment they occurred, just
in the order that they occurred and with the correct times that they
occurred specified. If you are getting samples out of order, there is no
reason why you can't put your data through a sorting filter before feeding
it to rrd. Note that any sorting filter will have to accumulate and delay
enough samples to sort, which introduces a delay from when the sample is
taken to when it is entered into rrd. The more "out-of-order" your input
samples can be, the longer the delay will have to be, but there is no reason
why you can't accumulate and sort a whole days worth of samples before
feeding them into rrd.

	You can't graph time-sequence data if you don't know the timestamps
of the samples...So either you cannot get data worth graphing in the first
place, or there is at least a useful approximation for the timestamps that
you can use. For rrd, I would suggest a close enough estimate for the
timestamps would be +-"step", though +-("step" * "steps") where "steps" is
for the smallest RRA would be OK.

> perhaps an idea to allow measurements to be inserted at whatever moment
> you desire, even if it's a time before the last update time :)
> 
	This can be done with a sorting pre-filter as described above. If
you really want something like this it can be written in about 12 lines of
Python.

	import os,sys,bisect,string
	try:
	    queue=eval(open('/var/local/queue.dat','r').read())
	except:
	    queue=[]
	for arg in sys.argv[2:]:
	    sample=( int(string.split(arg,':',1)[0]), arg )
	    bisect.insort(queue,sample)
	sorted,queue=queue[:-10],queue[-10:] # queue size of 10, modify as
needed
	if sorted: 
	   os.system('rrdtool update %s %s' % (argv[1],string.join(sorted)))
	open('/var/local/queue.dat','w').write(repr(queue))

	This is a simple wrapper around rrdtool update. It is invoked the
same way, minus the 'update' parameter, and it doesn't understand the
--template option. You also do not want to use the 'N' shorthand for the
sample times, because it will be wrong. It uses a queue to sort the samples,
and preserves the queue between invocations. If your CPU is stressed, you
could optimise this a fair bit. Someone has done a Python port of the rrd
perl piped input thingy that might even simplify this in addition to making
it faster. The existing queue size of 10 will allow for samples up to 10
places out of order. Extending this will introduce more lag but allow for
even more out-of-order samples.

	Note: I have not run this, there might be bugs.

> thanks,
> 
	wow.. sure ended up writing more than I intended :-)

> Itris
> 
> 

--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi