Matthieu Coudron <notifications@github.com> writes:
> `You just want to repeat a single download and measure its time,`
> Yes that's exactly it.
Right. Well, there are basically two ways you can go about this. Either
you create a test that runs only a single test, capture the delay as a
metadata item, and then the test multiple times to collect multiple data
points (which will each go into its own data file), and plot the CDF
over all of them (using a cdf_combine type plot). Or you go play with
IterationAggregator.
The combining of different runners into the toplevel data set is done by
aggregators; most of the tests are returning timeseries data, i.e. where
each runner is expected to return a timeseries data series. Single data
points for a whole test run is stored as metadata (in the series_meta
array).
However, there's also some old code that does single-data-point-per-run.
Before I realised that timeseries data was the most useful for my tests,
I actually started out with exactly what you are describing: Using each
test as a single data point and plotting those. That code still exists
in the form of the IterationAggregator; but you'd have to write a new
runner that outputs a single data point instead of the timeseries data,
and obviously you wouldn't get the bandwidth output over the duration of
the test.
I think that the easiest approach is the first one, since the timeseries
data is what's used most, and the other code might have bitrotted (not
sure). If you don't mind using netperf, it's just a matter of adding
ELAPSED_TIME as an output var and storing that in the metadata array.
Then we'd need to add support for passing negative durations to netperf
(that's how you specify a byte count), which is mostly a question of how
to have a good API in Flent. With this, you could use the existing tcp_*
tests and just add a plot to those...
You could do something similar in the iperf runner as well, of course,
it would just take a bit more parsing I think :)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.