Matthieu Coudron 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 ; done`), then plot all data files at once. > How can I get > ``` > 'TCP netperf::2': , > 'TCP netperf::3': , > 'TCP netperf::4': <-- 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 or view it on GitHub: https://github.com/tohojo/flent/issues/138#issuecomment-396176959