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:
0001-Initial-swag-at-bandwidth-rate-stepping.patch
Description: Binary data
On Aug 16, 2012, at 9:24 AM, Greg Sullivan <greg.sullivan@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html
