[smokeping-users] Re: RRDTool Filling In Unknown Values For Missing Pings

[hkclark at yahoo.com]

Hi Tobi,

First, *many* thanks for your excellent tools and for
replying to my note!

Yes, at first the "equi-spaced points on an
interpolated curve" issue caught me by surprise, but I
eventually got it down.  The issue I'm currently
dealing with might be related, but it seems to be a
little different.  Maybe an example would help explain
it best:

# Create a simplified Smokeping-like RRD
rrdtool create test_01.rrd --start 1000000000 --step
300   \
  DS:loss:GAUGE:600:0:20 DS:ping1:GAUGE:600:0:180  \
  RRA:AVERAGE:0.5:1:1008 RRA:AVERAGE:0.5:12:4320  \
  RRA:MIN:0.5:12:4320 RRA:MAX:0.5:12:4320  \
  RRA:AVERAGE:0.5:144:720 RRA:MAX:0.5:144:720 \
  RRA:MIN:0.5:144:720 
# 
# Load in some dummy data
rrdtool update test_01.rrd 1000000200:4:5
rrdtool update test_01.rrd 1000000521:4:5
rrdtool update test_01.rrd 1000000821:8:9
rrdtool update test_01.rrd 1000001121:U:5
rrdtool update test_01.rrd 1000001421:U:5
# Dump
rrdtool dump test_01.rrd > test_01.xml

Note that it’s putting in 3 values followed by 2 “U’s”
for the DS “loss”.

The dump shows:
    Time		loss			ping1
    1000000200	4.0000000000e+000	5.0000000000e+000
    1000000500	4.0000000000e+000	5.0000000000e+000
    1000000800	7.7200000000e+000	8.7200000000e+000
    1000001100	8.0000000000e+000	5.2800000000e+000
    1000001400	NaN			5.0000000000e+000

So, the loss value in the “1000000800” (3rd) row is
the "equi-spaced points on an interpolated curve"
issue, right?  I’m OK with that… yeah, as you point
out it’s a little “weird” for ping data, but it
doesn’t fundamentally change the results.  However,
the “1000001100” (4th) row is a little different… now
rather than storing a “NaN” it’s taking the
“un-interpolated value” from the previous timeslot.  

The reason it has come up: we are Smokeping’ing a site
with intermittent conectivity issues.  So one ping
might have 0/20 packet loss.  Then say the next time
drops 19 out of 20 – the users are saying, “How can it
show smoke when only one ping made it back?”  And if
you look in the RRD dump, it has “filled in” all the
“NaN” values with the values from the previous poll,
making the data look a lot “better” than it really is
(the “loss” DS value is accurate, but the “ping1”
through “ping20” DS values are “skewed”).  

I tried playing around with the keepalive & xff
values, but to no avail.  I have started looking at
the code for RRD to see if a patch might be able to
implement a more “strict” interpretation of a “U”
during an update -- but I must admit that I have been
doing Perl & Java so long that my C skills stink these
days. :-(  I'll keep trying, but it's slow going. :-)

If anyone has an idea of how to accomplish this, I’m
all ears!

Thanks!
Kennedy



--- Tobias Oetiker <oetiker at ee.ethz.ch> wrote:

> Yesterday hkclark at yahoo.com wrote:
> 
> > Is there a way to prevent RRDTool from filling in
> > unknown values from missing pings with the time
> from
> > the previous set of 20 pings?  For example, say 8
> of
> > the 20 pings fail, but just for a single "round"
> of
> > pings (all 20 of the previous "round" succeeded). 
> An
> > "rrdtool dump" shows that the 8 missing pings in
> the
> > "current round" have been filled in with the
> previous
> > round's numbers.  Is there a way to stop this
> > behavior?
> 
> Hi Kennedy,
> 
> the 'problem' is that rrdtool does not store the
> actual data but
> rather time-wise equi-spaced points on an
> interpolated curve ...
> with the pings this is a bit odd, as there is not
> realy a
> relationship between the second fastest ping in the
> first round and
> the second fastest ping in the second round ...,
> nevertheless it
> does work very well for drawing the 'smoke' but you
> should not try to read
> anything else into this data unless you have fully
> explored the
> inner workings of the Round Robin Database system
> and are sure the
> data does contain the information you are interested
> in ...
> 
> cheers
> tobi
> 
> -- 
>  ______    __   _
> /_  __/_  / /  (_) Oetiker @ ISG.EE, ETL F24.2, ETH,
> CH-8092 Zurich
>  / // _ \/ _ \/ /  System Manager, Time Lord, Coder,
> Designer, Coach
> /_/ \.__/_.__/_/   http://people.ee.ethz.ch/oetiker
> +41(0)44-632-5286
> 



	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail

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