[smokeping-users] Packet loss calculations in Smokeping

[Chris Wilson]

Hi Vern,

On Fri, 9 Feb 2007, Vern.Dias at VerizonWireless.com wrote:

>  I have received a question from our network management group concerning
>  how the packet loss is calculated by Smokeping.
>
>  I have tried to understand this and failed miserably.
>
>  For example, here is a record from one of my rrd files:

This is actually an RRD question, at least in part, which is not specific to 
Smokeping (Smokeping may be feeding the wrong data to rrdtool).

>  1170982800: NaN 5.3841740667e+00 3.5863971281e-02 3.4867749856e-02
>  3.4867749856e-02 3.4867749856e-02 3.4867749856e-02 3.5863971281e-02
>  3.5863971281e-02 3.5863971281e-02 3.5863971281e-02 3.5863971281e-02
>  3.9848856978e-02
>
>  Loss  5.3841740667e+00
>
>  Ping Median  00 3.5863971281e-02
>
>  Ping 1  3.4867749856e-02
>  Ping 2  3.4867749856e-02
>  Ping 3  3.4867749856e-02
>  Ping 4  3.4867749856e-02
>  Ping 5  3.5863971281e-02
>  Ping 6  3.5863971281e-02
>  Ping 7  3.5863971281e-02
>  Ping 8  3.5863971281e-02
>  Ping 9  3.5863971281e-02
>  Ping 10 3.9848856978e-02

There are NO lost pings in the above record, i.e. all ten pings have values 
rather than being NAN.

>  Where did the 5.3841740667e+00 for packet loss come from?  How was it
>  calculated?
>
>  Does the percentage reflecting in that calculation only come from this
>  specific RRD record?
>
>  How can a loss calculation base on 10 pings not return a loss percentage
>  that is 10%, 20% 30%, etc?
>
>  Or does it somehow span multiple records? All 10 fields in the record
>  show values, although many are exactly the same, which is highly
>  unlikely. I only see 3 unique values, which tells me that the packet
>  loss was more like 70% (three good response time numbers and Smokeping
>  likely just kept the previous value for the packets that were lost)?

How RRD calculates values is very complicated. RRD tries to fill in values for 
every row, even when no data was provided (e.g. when the rate of submission 
does not equal the step rate of the database). It does this by interpolating 
between the last known value and the newly submitted one across all the records 
which do not have values.

Perhaps this row which you give as an example was not really filled in at all, 
but interpolated between the previous and next rows?

Alternatively, you do not say whether this record is a primary data point (PDP) 
or one of the archives. Archives are summaries across multiple rows, normally 
the average, minimum or maximum of the data they contained. Most of the data in 
an RRD file is archives and not primary data points.

Also, the loss value is not exactly 5 because of this interpolation and 
summarisation, and because RRD stores floating point numbers rather than exact 
ones.

>  The information contained in this message and any attachment may be
>  proprietary, confidential, and privileged or subject to the work product
>  doctrine and thus protected from disclosure.  If the reader of this message
>  is not the intended recipient, or an employee or agent responsible for
>  delivering this message to the intended recipient, you are hereby notified
>  that any dissemination, distribution or copying of this communication is
>  strictly prohibited. If you have received this communication in error,
>  please notify me immediately by replying to this message and deleting it and
>  all copies and backups thereof.  Thank you.

Disclaimers of this type are not terribly helpful in postings to mailing lists. 
They are also a tragic waste of bandwidth. If you must have a disclaimer, 
please keep it short and sweet, or ask your legal department to do so. Thank 
you.

Cheers, Chris.
-- 
Aptivate | http://www.aptivate.org | Phone: +44 1223 760887
The Humanitarian Centre, Fenner's, Gresham Road, Cambridge CB1 2ES

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.