Hello, The drop-counter is mostly intended for the situation where you know that samples were lost before they even got as far as the agent software. For example, if you are reading from a hardware buffer queue and you discover that the buffer queue has overflowed since the last time you looked. In that scenario you know that some samples were lost, but you probably don't even know how many. All you can do is increment the drop counter (and if this is happening chronically then you might consider backing-off the hardware sampling rate).
Once a sample makes it into the agent software then (and only then) the sequence number can be incremented, because it will definitely be encoded into a datagram and given to UDP to be sent to the collector. Of course, remembering what the 'U' stands for, the datagram may be dropped in any number of places. It might not even make it off the box! However that is not something you have to keep track of. As long as you incremented the sequence number (and the all-important sample_pool counter) then any non-systematic packet-loss can be accommodated by the collector, and will manifest as a small increase in the effective-sampling-rate (e.g. 1-in-400 becomes 1-in-401). I hope this is clear. Regards, Neil On Mar 25, 2010, at 10:59 PM, the keralite wrote: > sFlow spec gurus, > If the sFlow agent drops a flow sample export datagram due to lack of > resources then the drops for that data source is incremented. What happens > to the squence_number that is reported in a flow sample? I assume that its > not incremented. OR does the agent increment both the sequence_number and > the drops fields? > TIA > ZC
