> And another possible source for those - if the application "goes out to > lunch" and does not read from the socket(s) for a length of time greater > than the sFlow counter sampling interval. When that happens (such as, > for example stopping program output to the terminal with Ctrl-S :) > multiple sFlow PDUs containing samples for the same entity/entities can > be queued-up in the socket buffer. > > There are two ways to address that. The first, and what I've done in my > own little program, is to enable SO_TIMESTAMP on the socket(s) on which > the sFlow PDUs are being received. By using the arrival timestamp > generated by the stack instead of one snapped by the program, the PDUs > will not suddenly seem to time compress after the application as > "returned from lunch." > > The other option, which is a bit more complicated, involves making use > of the millisecond uptime field of the sFlow PDU header to compute the > time deltas and use them when generating the timestamp given to RRD. I > suppose if one were particularly clever one could track the rate at > which time was advancing on the sFlow agent and compare that with the > rate at which it was advancing at the collector...
But wait, that's not all :) You can also get the "double update in the same second" messages out of RRD even if you are using the stack's SO_TIMESTAMP and the "time to milliseconds" option of contemporary RRD if the sFlow agent, trying to be helpful, decides to chuck-in a counter sample for an interface along with a flow sample it has taken on that interface, and that happens to be right around the time one receives a regularly scheduled counter sample for that interface. rick jones _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
