Suggestion: Add ramp-up for rate testing.

Suggestion: Add ramp-up for rate testing.

[Greg Sullivan]

I suggest adding a ramp-up time parameter that can be used to prevent
the rate testing from occurring until the ramp-up time has passed.
This will more accurately model the throughput capacity of streaming
systems that have a pre-load buffer to ride over the initial cache
warm-up period.

Greg.
p.s The rate stuff is working on Windows now - thanks Bruce.

Re: Suggestion: Add ramp-up for rate testing.

[Josh Carter]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

Greg (and all),

I actually did some work on this, however I didn't have it ready to push upstream. I used the existing "ratemin" and "rate" configuration options to represent the starting rate and the final (target) rate, then I added a "ratestep" option which added to the current rate every 5 "ratecycles".

Problem was, when I changed the rate, there was a brief spike in bandwidth for that bw measurement interval. I didn't determine if the problem was actually in the rate limiting (most likely), or in the bandwidth measurement (less likely but possible). In any case, I didn't want to offer the patch until that was solved.

I'm not able to work on this right now, so I'll pass along the patch as-is. Maybe someone else can take it and run with it.

Best regards,
Josh


[-- Attachment #2: 0001-Initial-swag-at-bandwidth-rate-stepping.patch --]
[-- Type: application/octet-stream, Size: 4626 bytes --]

From 0a759076c3e7bfdc9610ddd03c20cb3b42f320da Mon Sep 17 00:00:00 2001
From: Josh Carter <public@joshcarter.com>
Date: Wed, 16 Nov 2011 15:57:36 -0700
Subject: [PATCH 1/2] Initial swag at bandwidth rate stepping.

- Adding "ratestep=" option to config files; when used with "rate="
  option, it will step the rate up by ratestep every (ratecycle * 5)
  milliseconds. (Yea, should make the step interval configurable
  separately.)

- Added step_rate() near the end of do_io(), just after we do the
  check_min_rate() part.

Currently very fiddly; seems to get blips in bandwidth just after a
rate step, also at high rates/steps it messes up bandwidth logging.
Need feedback from mailing list.
---
 fio.c     |   40 ++++++++++++++++++++++++++++++++++++++++
 fio.h     |    4 +++-
 init.c    |    4 ++++
 options.c |    8 ++++++++
 4 files changed, 55 insertions(+), 1 deletions(-)

diff --git a/fio.c b/fio.c
index 5b58ab8..9063c03 100644
--- a/fio.c
+++ b/fio.c
@@ -341,6 +341,39 @@ static int check_min_rate(struct thread_data *td, struct timeval *now,
 	return ret;
 }
 
+static int __step_rate(struct thread_data *td, struct timeval *now,
+		       enum fio_ddir ddir)
+{
+        unsigned long spent;
+        unsigned long long new_rate;
+	
+	assert(ddir_rw(ddir));
+
+	if (!td->o.ratestep[ddir])
+		return 0;
+
+	spent = mtime_since(&td->lastratestep[ddir], now);
+
+	if (spent < td->o.ratecycle * 5)
+	        return 0;
+		
+        new_rate = td->rate_bps[ddir] + td->o.ratestep[ddir];
+        td->o.rate[ddir] = td->rate_bps[ddir] = new_rate;
+
+	memcpy(&td->lastratestep[ddir], now, sizeof(*now));
+	return 0;
+}
+
+static int step_rate(struct thread_data *td, struct timeval *now)
+{
+	int ret = 0;
+
+	ret |= __step_rate(td, now, DDIR_READ);
+	ret |= __step_rate(td, now, DDIR_WRITE);
+
+	return ret;
+}
+
 static inline int runtime_exceeded(struct thread_data *td, struct timeval *t)
 {
 	if (!td->o.timeout)
@@ -813,6 +846,8 @@ sync_done:
 				td_verror(td, EIO, "check_min_rate");
 				break;
 			}
+			
+                        step_rate(td, &comp_time);
 		}
 
 		if (td->o.thinktime) {
@@ -1237,6 +1272,11 @@ static void *thread_main(void *data)
 	fio_gettime(&td->epoch, NULL);
 	getrusage(RUSAGE_SELF, &td->ru_start);
 
+	if (td->o.ratestep[0] || td->o.ratestep[1]) {
+		memcpy(&td->lastratestep[0], &td->epoch, sizeof(td->epoch));
+		memcpy(&td->lastratestep[1], &td->epoch, sizeof(td->epoch));
+	}
+
 	clear_state = 0;
 	while (keep_running(td)) {
 		fio_gettime(&td->start, NULL);
diff --git a/fio.h b/fio.h
index cc1f65f..36b15aa 100644
--- a/fio.h
+++ b/fio.h
@@ -212,6 +212,7 @@ struct thread_options {
 
 	unsigned int rate[2];
 	unsigned int ratemin[2];
+	unsigned int ratestep[2];
 	unsigned int ratecycle;
 	unsigned int rate_iops[2];
 	unsigned int rate_iops_min[2];
@@ -361,6 +362,7 @@ struct thread_data {
 	unsigned long rate_bytes[2];
 	unsigned long rate_blocks[2];
 	struct timeval lastrate[2];
+    struct timeval lastratestep[2];
 
 	unsigned long long total_io_size;
 	unsigned long long fill_device_size;
@@ -659,7 +661,7 @@ static inline int __should_check_rate(struct thread_data *td,
 	 * If some rate setting was given, we need to check it
 	 */
 	if (o->rate[ddir] || o->ratemin[ddir] || o->rate_iops[ddir] ||
-	    o->rate_iops_min[ddir])
+	    o->rate_iops_min[ddir] || o->ratestep[ddir])
 		return 1;
 
 	return 0;
diff --git a/init.c b/init.c
index 482ce09..717dfc5 100644
--- a/init.c
+++ b/init.c
@@ -498,6 +498,10 @@ static int fixup_options(struct thread_data *td)
 		log_err("fio: minimum rate exceeds rate\n");
 		ret = 1;
 	}
+	if ((o->ratestep[0] && !o->rate[0]) || (o->ratestep[1] && !o->rate[1])) {
+		log_err("fio: ratestep requires initial rate also set\n");
+                ret = 1;
+	}
 
 	if (!o->timeout && o->time_based) {
 		log_err("fio: time_based requires a runtime/timeout setting\n");
diff --git a/options.c b/options.c
index 53c3a82..a276bcb 100644
--- a/options.c
+++ b/options.c
@@ -1772,6 +1772,14 @@ static struct fio_option options[FIO_MAX_OPTS] = {
 		.help	= "Job must meet this rate or it will be shutdown",
 		.parent	= "rate",
 	},
+        {
+        	.name	= "ratestep",
+        	.type	= FIO_OPT_INT,
+        	.off1	= td_var_offset(ratestep[0]),
+        	.off2	= td_var_offset(ratestep[1]),
+        	.help	= "Job will increment bandwidth rate by this amount each ratecycle",
+        	.parent	= "rate",
+        },
 	{
 		.name	= "rate_iops",
 		.type	= FIO_OPT_INT,
-- 
1.7.4.4


[-- Attachment #3: Type: text/plain, Size: 667 bytes --]


On Aug 16, 2012, at 9:24 AM, Greg Sullivan <greg.sullivan@sullivang.net> wrote:

> I suggest adding a ramp-up time parameter that can be used to prevent
> the rate testing from occurring until the ramp-up time has passed.
> This will more accurately model the throughput capacity of streaming
> systems that have a pre-load buffer to ride over the initial cache
> warm-up period.
> 
> Greg.
> p.s The rate stuff is working on Windows now - thanks Bruce.
> --
> To unsubscribe from this list: send the line "unsubscribe fio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Suggestion: Add ramp-up for rate testing.

[Greg Sullivan]

Thanks Josh. Note that at the moment, I'd be happy to just have a
simple time delay before ratemin testing begins.

Greg.

On 17/08/2012, Josh Carter <public@joshcarter.com> wrote:
> Greg (and all),
>
> I actually did some work on this, however I didn't have it ready to push
> upstream. I used the existing "ratemin" and "rate" configuration options to
> represent the starting rate and the final (target) rate, then I added a
> "ratestep" option which added to the current rate every 5 "ratecycles".
>
> Problem was, when I changed the rate, there was a brief spike in bandwidth
> for that bw measurement interval. I didn't determine if the problem was
> actually in the rate limiting (most likely), or in the bandwidth measurement
> (less likely but possible). In any case, I didn't want to offer the patch
> until that was solved.
>
> I'm not able to work on this right now, so I'll pass along the patch as-is.
> Maybe someone else can take it and run with it.
>
> Best regards,
> Josh
>
>

Re: Suggestion: Add ramp-up for rate testing.

[Jens Axboe]

On 08/16/2012 05:24 PM, Greg Sullivan wrote:
> I suggest adding a ramp-up time parameter that can be used to prevent
> the rate testing from occurring until the ramp-up time has passed.
> This will more accurately model the throughput capacity of streaming
> systems that have a pre-load buffer to ride over the initial cache
> warm-up period.

There's already a ramp time setting, and the rate will not be checked
before that has passed. Not sure what extra setting you would like? A
ramp time, and then a rate ramp time after that?

-- 
Jens Axboe

Re: Suggestion: Add ramp-up for rate testing.

[Greg Sullivan]

On 17 August 2012 16:25, Jens Axboe <axboe@kernel.dk> wrote:
> On 08/16/2012 05:24 PM, Greg Sullivan wrote:
>> I suggest adding a ramp-up time parameter that can be used to prevent
>> the rate testing from occurring until the ramp-up time has passed.
>> This will more accurately model the throughput capacity of streaming
>> systems that have a pre-load buffer to ride over the initial cache
>> warm-up period.
>
> There's already a ramp time setting, and the rate will not be checked
> before that has passed. Not sure what extra setting you would like? A
> ramp time, and then a rate ramp time after that?
>

Thanks - that's exactly what I wanted, and I apologise for not reading
the manual (again). Note that I did scroll up and down a bit around
the rate related settings and didn't see anything related to ramping,
but I should have looked harder.

Regards,
Greg.