Skip to contentSkip to conversation

suggestion: patch to make per-thread IOPS more accurate

DISCUSSION Andrew Theurer 1 participant 1 message Feb 20, 2015 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

#1 lore raw
Quoted 7 lines

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.

Quoted 5 lines
     "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.

Quoted 48 lines

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 renamed from stat.c.sav +4 -3
@@ -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]);
Quoted 1 line

json_object_add_value_int(dir_object, "short_ios", ts->short_io_u[ddir]);

-Andrew