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 <b...@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 <b...@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.mc...@inmon.com> > >> > > >> > Thanks, applied to master and branch-2.6. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
