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

[Ben Pfaff]

Thanks for the hint.  I pushed a fix to master and branch-2.6.

On Fri, Sep 02, 2016 at 02:58:15PM -0700, Neil McKee wrote:
> 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.