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
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.d
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 eno
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 wrote:
> On Mon, Aug 29, 2016 at 03:32
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 im
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 variab
