<html><head><title>Re: [smokeping-users] Smokeping false packet loss?</title>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
</head>
<body>
<br><br>
<span style=" font-family:'courier new'; font-size: 9pt; color: #800000;"><b>ET> I do suspect I also have false loss in my graphs. I'm on a DSL line<br>
ET> with multicast IPTV. The IPTV does not have any retransmitt or error<br>
ET> correction, and I extremly rearly see any blocking in the image.<br>
ET> Also, manual pings very rearly have any loss. But according to my 10<br>
ET> day graphs I'm lossing 3/20.<br>
<br>
</b><span style=" color: #000000;">While I suppose it's possible that smokeping is somehow not recording the results of fping properly, I doubt highly that this is actually the case. What does happen, I suspect, is that when it aggregates the data [as it's pruning the RRD's from full resolution samples to the next tiers where it's grouping more than a single sample into an "average"] it doesn't aggregate data the way you expect.<br>
<br>
I haven't seen a discussion about how it does this, but I'd guess that if it's compressing ten samples into 1, for example, and one of the ten samples had 10% loss and the others no loss, it would be better to show the loss over that period as something like 5% or even 10%, rather than 1%. [i.e. A loss condition is vastly more important to "see" than a no-loss condition.]<br>
<br>
The "averaging" is probably not an average, but a "worst" case. So, if one sample in ten had a ten percent loss, then the aggregate will show the worst case of the aggregated samples of ten percent.<br>
<br>
This appears to mirror what I see in my graphs. Small, irregular losses show up more "strongly" in compressed second and third tier RRD graphs. And I think that is how it should be.<br>
<br>
So, if you have the occasional loss sample, as it compresses these full resolution samples into aggregated data, you'll see more non-green [non-zero-loss] samples than you would in the full resolution samples.<br>
<br>
And before you complain and ask for it to be different, let me pipe in and say; No, please don't make it different. Losses are bad, very bad. I want to have losses emphasized, not diluted away by the other ten or twenty samples that didn't have a loss. If your provider is losing any traffic, it's a problem and smokeping ought to clearly call these out.<br>
<br>
One other note on the graphs you posted. I also notice pretty strong increases in latency during those times you don't think you're having loss. That would correlate with what usually happens when loss actually occurs. So, I think it's a confirmation that loss really is happening, just not in all or even most samples.<br>
<br>
HTH<br>
<br>
-Greg</body></html>