On 20 August 2012 22:43, Jens Axboe <axboe@xxxxxxxxx> wrote:
> On 08/20/2012 03:42 AM, Greg Sullivan wrote:
>> On 19 August 2012 22:39, Greg Sullivan <greg.sullivan@xxxxxxxxxxxxx> wrote:
>>> I'm finding that the throughput is varying wildly during a run - more
>>> than I think is probably normal. It happens regardless of whether I
>>> limit by data rate or io rate, although I think it's worse when I
>>> limit by io.
>>>
>>> Here is a test job followed by the output. The io rate fluctuated
>>> wildly - I watched it in the Windows Performance Monitor. The io rate
>>> should be extremely easy to maintain. The "CR=80" looks suspicious -
>>> why is there an 80 there when I requested 40?
>> [stuff removed]
>>
>> I tried the same test on Ubuntu, and I think it's working properly -
>> the iops figures displayed by fio are relatively constant as the test
>> runs. (although I'm having trouble relating the the output of iostat
>> to the actual workload that should be generated) I still get the
>> CR=<double the requested rate> on Ubuntu, so I assume this is normal.
>> The iops figures over on the right of the output look kosher. (as they
>> do on Windows, except for the wide fluctuations)
>
> The CR=x/y reading is as follows:
>
> - x is the target read _and_ write commit rate. If your workload was a
> read/write workload, it'd be 40 from each. I should change that, it's
> confusing. But for now, suffice to say that it is to be expected and
> the 40 is parsed/understood by fio.
> - y is the same, but the minimum rate (if that is set).
>
> See below patch, should make it more easily understandable.
>
> As to the Windows rate fluctuations - a quick guess would be that the
> timing is too coarse on Windows.
>
> diff --git a/eta.c b/eta.c
> index 9114595..552845d 100644
> --- a/eta.c
> +++ b/eta.c
> @@ -285,11 +285,18 @@ int calc_thread_status(struct jobs_eta *je, int force)
> || td->runstate == TD_FSYNCING
> || td->runstate == TD_PRE_READING) {
> je->nr_running++;
> - je->t_rate += td->o.rate[0] + td->o.rate[1];
> - je->m_rate += td->o.ratemin[0] + td->o.ratemin[1];
> - je->t_iops += td->o.rate_iops[0] + td->o.rate_iops[1];
> - je->m_iops += td->o.rate_iops_min[0] +
> - td->o.rate_iops_min[1];
> + if (td_read(td)) {
> + je->t_rate += td->o.rate[DDIR_READ];
> + je->t_iops += td->o.rate_iops[DDIR_READ];
> + je->m_rate += td->o.ratemin[DDIR_READ];
> + je->m_iops += td->o.rate_iops_min[DDIR_READ];
> + }
> + if (td_write(td)) {
> + je->t_rate += td->o.rate[DDIR_WRITE];
> + je->t_iops += td->o.rate_iops[DDIR_WRITE];
> + je->m_rate += td->o.ratemin[DDIR_WRITE];
> + je->m_iops += td->o.rate_iops_min[DDIR_WRITE];
> + }
> je->files_open += td->nr_open_files;
> } else if (td->runstate == TD_RAMP) {
> je->nr_running++;
>
> --
> Jens Axboe
>
I have now done a basic test of the rate functionality on Ubuntu, and
it seems to be working fine. I am more confident now that there is
indeed a problem when running fio on Windows.
Greg.
--
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
