> The following small patch to stat.c (using fio 2.2.4 from github) outputs
> IOPS field in JSON format as a floating point number instead of an integer.
> This improves accuracy in case where fio --client runs use lots of threads
> with single-digit IOPS per thread. It seems to work, here's a snippet of
> output from a short fio run with rate_iops=10 in the job file.
>
> "write" : {
> "io_bytes" : 6464,
> "bw" : 646,
> "iops" : 10.10,
> "runtime" : 10000,
Thanks for this. I have applied the patch, and it works fine for me. Very
useful when testing with many fio jobs on slower storage.
> Why the patch: IOPS number is rounded to integer in stats.c calls to
> num2str(). This doesn't sound like much of a problem because in many use
> cases, with large IOPS number the error is negligible. But in this use case
> where we have many threads (we would like to get into the thousands
> eventually), the IOPS/thread may be quite low and integer rounding can
> introduce significant error. For example, if we are doing 5,000 IOPS over
> 1,000 threads, average throughput is 5 IOPS and potential error is ~20%, but
> some threads could have much higher error in IOPS because of integer format.
>
> background: fio's --client option could prove *extremely* useful for work
> where we inject I/O workload from tens, hundreds or even thousands of VMs to
> an OpenStack, container or other virtualization environment. I really like
> this feature combined with "fio --server --daemonize=/var/run/fio-svr.pid"
> command run on workload generators, because it means that we don't have to
> use ssh/pdsh to start up a connection and launch the workload generator on
> each host. ssh is problematic for this, I have to throttle it because it
> locks up if you have too many concurrent ssh sessions starting up. pdsh is
> better but still has limits because you actually have to start each thread
> up from scratch, sometimes in competition with the workload you want to
> measure.
>
> --- stat.c.sav 2015-01-23 16:22:14.566717417 -0500
> +++ stat.c 2015-01-23 16:49:53.287962156 -0500
> @@ -674,7 +674,8 @@
> struct group_run_stats *rs, int ddir, struct json_object
> *parent)
> {
> unsigned long min, max;
> - unsigned long long bw, iops;
> + unsigned long long bw;
> + double iops;
> unsigned int *ovals = NULL;
> double mean, dev;
> unsigned int len, minv, maxv;
> @@ -698,12 +699,12 @@
> uint64_t runt = ts->runtime[ddir];
>
> bw = ((1000 * ts->io_bytes[ddir]) / runt) / 1024;
> - iops = (1000 * (uint64_t) ts->total_io_u[ddir]) / runt;
> + iops = (1000.0 * (uint64_t) ts->total_io_u[ddir]) / runt;
> }
>
> json_object_add_value_int(dir_object, "io_bytes", ts->io_bytes[ddir] >>
> 10);
> json_object_add_value_int(dir_object, "bw", bw);
> - json_object_add_value_int(dir_object, "iops", iops);
> + json_object_add_value_float(dir_object, "iops", iops);
> json_object_add_value_int(dir_object, "runtime", ts->runtime[ddir]);
> json_object_add_value_int(dir_object, "total_ios",
> ts->total_io_u[ddir]);
> json_object_add_value_int(dir_object, "short_ios",
> ts->short_io_u[ddir]);
-Andrew
--
To unsubscribe from this list: send the line "unsubscribe fio" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
