In this case, the counter export interval was set to 20 seconds and the blue line, trending the ifinucastpkts counter, shows that it can take up to 40 seconds before the counter metric fully reflects a change in traffic level (illustrating the frequency resolution bounds imposed by Nyquist-Shannon). The frames metric, calculated from packet samples, responds far more quickly, immediately detecting a change in traffic and fully reflecting the new value within a few seconds.
The counter push mechanism used by sFlow is extremely efficient, permitting faster counter updates than are practical using large scale counter polling - see Push vs Pull. Reducing the counter export interval below 20 seconds would increase the responsiveness, but at the cost of increased overhead and reduced scaleability. On the other hand, packet sampling automatically allocates monitoring resources to busy links, providing a highly scaleable way to quickly detect traffic flows wherever they occur in the network, see Eye of Sauron.
The difference in responsiveness is important when driving software defined networking applications, where the ability to rapidly detecting large flows ensures responsive and stable controls. Packet sampling also provides richer detail than counters, allowing a controller to identify the root cause of traffic increases and drive corrective actions.
While not as responsive as packet sampling, counter updates provide important complementary functionality:
- Counters are maintained in hardware and provide precise traffic totals.
- Counters capture rare events, like packet discards, that can severely impact performance.
- Counters report important link state information, like link speed, LAG group membership etc.