[ovs-dev] [PATCH] Flush freshly-polled sFlow counters promptly.

[Neil McKee]

Yes,  the output is OK.    In fact,  if you change the time/warp in
ofproto-dpif.at so that it only advances the monotonic clock by 2
seconds during the test instead of 3 (see below),  then it flushes out
the same number of counter samples,  and the only differences that
appear in tests/testsuite.dir/1075/testsuite.log are to the datagram
sequence numbers for the counter samples.    Very much as expected.


diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
index 8e5fde6..143c868 100644
--- a/tests/ofproto-dpif.at
+++ b/tests/ofproto-dpif.at
@@ -5267,7 +5267,7 @@ m4_define([CHECK_SFLOW_SAMPLING_PACKET],

   dnl sleep long enough to get more than one counter sample
   dnl from each datasource so we can check sequence numbers
-  ovs-appctl time/warp 3000 100
+  ovs-appctl time/warp 2000 100
   OVS_VSWITCHD_STOP
   OVS_APP_EXIT_AND_WAIT([test-sflow])

------
Neil McKee
InMon Corp.
http://www.inmon.com


On Fri, Sep 2, 2016 at 12:51 PM, Ben Pfaff <blp at ovn.org> wrote:
> I see the failing tests.
>
> If you can read the new results of the tests and verify for me that
> they're still a correct set of results, then I'll push a fix that
> updates the expected results.
>
> On Fri, Sep 02, 2016 at 12:03:21PM -0700, Neil McKee wrote:
>> This one perturbs the output ordering just enough to fail two of the
>> sflow unit tests.  Sorry I didn't notice that before.  I'll post
>> another patch for that.
>>
>> Neil
>> ------
>> Neil McKee
>> InMon Corp.
>> http://www.inmon.com
>>
>>
>> On Fri, Sep 2, 2016 at 11:47 AM, Ben Pfaff <blp at ovn.org> wrote:
>> > On Mon, Aug 29, 2016 at 03:32:41PM -0700, Neil McKee wrote:
>> >> This patch changes the order of the steps that are followed
>> >> every second in the sFlow agent.  By moving the receiver_tick()
>> >> step to the end,  we ensure that any counters that were polled
>> >> during the poller_tick() step are flushed immediately to the
>> >> sFlow collector.  This eliminates what was a variable time-delay
>> >> between counters being polled and being flushed.
>> >>
>> >> The variable time-delay that this eliminates could be up to
>> >> a second because counters lingering in the output buffer could be
>> >> flushed at any time by the arrival of random packet-samples.
>> >>
>> >> Since the sFlow standard does not require that a poll-timestamp be sent
>> >> along with the counters the collector must use his receive-time as the
>> >> timestamp, so that extra second of variable delay was "stretching or
>> >> shrinking" the time between successive counter readings.  This
>> >> affected any counter-rate calculation that was based only on the delta
>> >> between sucessive samples. The effect was small with a polling
>> >> interval of 60 seconds: just +/- 2%.  But the effect grew larger
>> >> when faster polling was configured.  For example, if the counters
>> >> were pushed every 5 seconds then the instantaneous rate
>> >> calculations could wander by +/- 20%.  For a thorough analysis
>> >> of this problem,  see Rick Jones' paper:
>> >>
>> >> "High Frequency sFlow v5 Counter Sampling"
>> >> ftp://ftp.netperf.org/papers/high_freq_sflow/hf_sflow_counters.pdf
>> >>
>> >> So this patch makes it possible to obtain usable results even
>> >> when high-frequency polling is configured.
>> >>
>> >> Signed-off-by: Neil McKee <neil.mckee at inmon.com>
>> >
>> > Thanks, applied to master and branch-2.6.