Flent-users discussion archives
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <notifications@github.com>
To: tohojo/flent <flent@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Subject: Re: [Flent-users] [tohojo/flent] completion delay for an iperf script (#138)
Date: Mon, 11 Jun 2018 02:15:17 -0700	[thread overview]
Message-ID: <tohojo/flent/issues/138/396176959@github.com> (raw)
In-Reply-To: <tohojo/flent/issues/138@github.com>

[-- Attachment #1.1: Type: text/plain, Size: 4236 bytes --]

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
> ```

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

> ...
> -- 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...


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:

[-- Attachment #1.2: Type: text/html, Size: 13078 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

Flent-users mailing list

  parent reply	other threads:[~2018-06-11  9:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <tohojo/flent/issues/138@github.com>
2018-06-07  8:57 ` Toke Høiland-Jørgensen
2018-06-07 10:01 ` Toke Høiland-Jørgensen
2018-06-08 10:20 ` Toke Høiland-Jørgensen
2018-06-08 10:55 ` Toke Høiland-Jørgensen
2018-06-11  9:15 ` Toke Høiland-Jørgensen [this message]
2018-06-11  9:36 ` Toke Høiland-Jørgensen
2018-06-11 12:20 ` Toke Høiland-Jørgensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://lists.flent.org/postorius/lists/flent-users.flent.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tohojo/flent/issues/138/396176959@github.com \
    --to=notifications@github.com \
    --cc=flent@noreply.github.com \
    --cc=reply+01ead4bf4b97bee00364cb164ba7f4421fcc21ce44da74b692cf000000011735ffa592a169ce13aceaa7@reply.github.com \
    --cc=subscribed@noreply.github.com \
    --subject='Re: [Flent-users] [tohojo/flent] completion delay for an iperf script (#138)' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox