Matthieu Coudron <notifications@github.com> writes:
> I used to have
> ```
> Runner aggregation finished
> ERROR: No data to aggregate. Run with -L and check log file to investigate.
> ```
> with in log
> ```
> ELAPSED_TIME=0.00
Yeah, this is an issue with netperf; it'll only output time in 10-ms
intervals. So you'll need to have enough data for the transfer to take
longer than this.
The 'no data to aggregate' is because there are no intermediate data
points output by netperf. For very short transfers, you could fiddle the
step size parameter to get output for smaller intervals.
If you need to run tests that large, I guess the 'no data to aggregate'
error could be made non-fatal in the case where there are valid metadata
results. But I assume your 'real' tests are going to be on lower
bandwidth links so they'll take longer (and thus this will be less of an
issue)?
> ...
> -- OUTPUT START -->{'TCP netperf::1': [],
> 'TCP netperf::2': [],
> 'TCP netperf::3': [],
> 'TCP netperf::4': [],
> 'TCP netperf::5': []}<-- OUTPUT END --
> ```
> as if ELAPSED_TIME being 0.00 wouldn't count as a result.
>
> I increased the byte count and it started producing result
> ```
> 2018-06-11 11:38:01,160 [flent.aggregators] DEBUG: Runner aggregation finished
> -- OUTPUT START -->{'TCP netperf::1': [[1528684679.972, 41611.46]],
> 'TCP netperf::2': [[1528684679.99, 45512.46]],
> 'TCP netperf::3': [[1528684680.044, 45546.14]],
> 'TCP netperf::4': [[1528684680.008, 46227.74]],
> 'TCP netperf::5': [[1528684680.026, 46214.39]]}<-- OUTPUT END --
>
>
> ```
> but these don't seem to be the ELAPSED_TIME.
Yeah, so this is because we are still using the timeseries run mode, so
the actual data points being produced are the bandwidth measurements
that netperf produce. So the elapsed time is stored as metadata, and we
basically ignore the other results.
> I've tried using this
> ```
> DATA_SETS = o([
> ('TCP netperf',
> {
> 'test': 'TCP_STREAM',
> 'host': HOST,
> 'length': 10,
> 'bytes': 100000000,
> 'duplicates': 5,
> # 'units': 'Mbits/s',
> 'runner': 'netperf_demo',})
> ])
>
> PLOTS['iperf_delay'] = {'description': 'Netperf completion time',
> 'type': 'cdf_combine',
> 'group_by': 'groups_concat',
> 'series': [
> # when duplicates is used the name is changed to e.g.:
> # Started NetperfDemoRunner idx 4 ('TCP netperf::5')
> # thus we need to use the glob
>
> {'data': glob('TCP netperf*'),
> 'label': 'completion delay (ms)',
> 'combine_mode': 'meta:ELAPSED_TIME'
> }]
> }
> ```
> and it displays an empty plot. when opening the tcp_iperf_delay-2018-06-07T143147.599875.flent it seems like all elapsed time were 0.02. I wanted to modify these values in place and regenerate a plot from the modified tcp_iperf_delay-2018-06-07T143147.599875.flent but couldn't find a way out.
Well, this should more or less work, I think. However, you only get one
data point to plot here; the 5 repetitions are not going to be five data
points to plot a CDF over; they are going to be 5 different series with
one datapoint each.
To get multiple datapoints, you'd need to run multiple tests (`for s in
$(seq 10); do flent <args>; done`), then plot all data files at once.
> How can I get
> ```
> 'TCP netperf::2': <ElapsedTime2>,
> 'TCP netperf::3': <ElapsedTime3>,
> 'TCP netperf::4': <ElapsedTime4><-- OUTPUT END --
> ```
> and then plot the cdf of it ? maybe that's not how it works, and I shouldn't care about the `'TCP netperf::2': []` data since ELAPSED_TIME is metadata ? it really looks like magic as it's kind of DSL mixed with python.
See above; you are right that you should just ignore those data points ;)
And yeah, this is really a DSL; it's just Python because that was easier
than coming up with a full DSL myself. I've been thinking about changing
it, but, well, that is a different subject...
-Toke
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.