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@inmon.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>