Re: [Cake] cake flenter results round 2

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Georgios Amanakis <gamanakis@gmail.com> writes:

> I am troubled by the number of data points flent reports for some pings and
> uploads in this setup. A typical ack-filter result, similar to rrul2 I
> posted before, looks like this:
> Summary of rrul test run 'rrul_cakeeth_ds3_900mbit_45mbit_ack' (at
> 2017-11-29 14:37:5
> 5.719180):
>
>                              avg       median          # data pts
>  Ping (ms) ICMP   :       100.29       100.00 ms              337
>  Ping (ms) UDP BE :       297.62       100.20 ms              156
>  Ping (ms) UDP BK :       409.84       100.20 ms              109
>  Ping (ms) UDP EF :       414.94       100.20 ms              121
>  Ping (ms) avg    :       374.13       100.05 ms              343
>  TCP download BE  :       206.39       217.48 Mbits/s         301
>  TCP download BK  :       163.05       163.81 Mbits/s         301
>  TCP download CS5 :       206.40       217.50 Mbits/s         301
>  TCP download EF  :       203.18       215.23 Mbits/s         301
>  TCP download avg :       194.75       202.59 Mbits/s         301
>  TCP download sum :       779.02       810.36 Mbits/s         301
>  TCP totals       :       781.55       810.66 Mbits/s         301
>  TCP upload BE    :         1.86        24.68 Mbits/s          23
>  TCP upload BK    :         0.15         1.72 Mbits/s          24
>  TCP upload CS5   :         0.25         2.26 Mbits/s          30
>  TCP upload EF    :         0.27         2.15 Mbits/s          29
>  TCP upload avg   :         0.63         7.59 Mbits/s          36
>  TCP upload sum   :         2.53        30.38 Mbits/s          36
>
> Shouldn't all "# data pts" be ~300?

Ideally, yes. However, netperf works by estimating after how many bytes
it will need to emit the next data point. If this estimate is wrong
(which most often happens at very low bandwidths as you are seeing
here), the number of data points can be a lot lower. The average values
should still be correct, though; they are calculated at the end of the
test as bytes transmitted / test duration.

Something similar happens with the UDP results, with the added
complication that these can stop entirely when there is packet loss.
Flent has recently learned how to support the irtt tool
(https://github.com/peteheist/irtt/) for the UDP latency measurements,
which emits isochronous latency probes in the same way as the regular
ping tool. If you install irtt and use the latest git version of Flent,
it should be picked up automatically and used for the UDP ping
measurements.

-Toke