Hello Oliver,
Here is the math:
https://sflow.org/packetSamplingBasics/
But what this means in practice is that you should select a packet-sampling
rate that does not stress the pipeline or impact performance at all.
Something like 1-in-1000 is quite common.
I haven't looked at the pmacct source code so I don't know what it does,
but just multiplying the bytes by the sampling-rate will only give you a
crude approximation. The sFlow protocol allows you to be much more accurate
that this because it always includes the latest value of the "sample pool",
a monotonic counter indicating the total number of packets that could have
been sampled. When you look at the number of samples you
successfully received (some may have been lost in transit) you can compute
the *effective* sampling rate, ESR:
ESR = delta(sample_pool) / count(samples)
which should be close to the 1:N setting you configured, but might not be
exactly the same. Now if you scale up using ESR you should have a number
that converges to the right answer. And as the paper above shows, the more
samples you have, the more accurate you will be.
Another tool you might use to verify your setup is the "sflow-test" app
that runs on the sFlow-RT platform, which is freely available for
non-production experiments like this. It has the nice property that you
can see the measured traffic level update every second, and compare it
directly with the interface counters that sFlow also streams:
https://blog.sflow.com/2015/11/sflow-test.html
--
Neil McKee
InMon Corp.
On Tue, Feb 4, 2020 at 12:18 PM Oliver Dzombic wrote:
> Hi,
>
> the goal is to math sflow into real traffic consumption.
>
> I am testing using pmacct with the sfacctd as collector software.
>
> I am using iperf3 to generate traffic between two hosts.
>
> From my understanding if i do a sflow export configuration like:
>
> agent : "127.0.0.1"
> external_ids: {}
> header : 1518
> polling : 1
> sampling: 1
> targets : ["127.0.0.1:6343"]
>
>
> Then every second, every package will be exported to the collector.
>
> When i send for 5 seconds a total amount of 2.36 GBytes, i would expect
> that the sum of the "bytes" would match with the 2.36 GB.
>
> The numbers that were collected were:
>
> {"event_type": "purge", "vlan": 0, "ip_src": "192.168.178.1", "ip_dst":
> "192.168.178.2", "packets": 192, "bytes": 13519}
>
> {"event_type": "purge", "vlan": 0, "ip_src": "192.168.178.1", "ip_dst":
> "192.168.178.2", "packets": 435, "bytes": 30474}
>
> {"event_type": "purge", "vlan": 0, "ip_src": "192.168.178.1", "ip_dst":
> "192.168.178.2", "packets": 388, "bytes": 27180}
>
> {"event_type": "purge", "vlan": 0, "ip_src": "192.168.178.1", "ip_dst":
> "192.168.178.2", "packets": 318, "bytes": 22260}
>
> {"event_type": "purge", "vlan": 0, "ip_src": "192.168.178.1", "ip_dst":
> "192.168.178.2", "packets": 436, "bytes": 30544}
>
> {"event_type": "purge", "vlan": 0, "ip_src": "192.168.178.1", "ip_dst":
> "192.168.178.2", "packets": 340, "bytes": 23990}
>
>
> And the math is not really matching.
>
> I repeated the test, changing the sample rate ( and multiply the sum of
> bytes with the sample rate ).
>
> But that did not really help. The numbers are changing, but not to
> amount of traffic that had been transfered.
>
>
> Since i assume that old established software like pmacct aswell as
> openvswitch will deliver correct numbers.
>
> So as it seems to me, my math is (still) as good as my teachers told me
> in the college.
>
> Could someone please point me into the right direction how to math that ?
>
> Thank you very much !
>
> --
> Mit freundlichen Gruessen / Best regards
>
> Oliver Dzombic
> Layer7 Networks
>
> mailto:i...@layer7.net
>
> Anschrift:
>
> Layer7 Networks GmbH
> Zum Sonnenberg 1-3
> 63571 Gelnhausen
>
> HRB 96293 beim Amtsgericht Hanau
> Geschäftsführung: Oliver Dzombic
> UST ID: DE259845632
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
