RE: FIO latency bin midpoint vs upper limit capture

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Abhishek, 

Thanks for the detail.  I haven't been using the json output so didn't make the connection.  I see what you are talking about now.  

Kris Davis

-----Original Message-----
From: abhishek koundal [mailto:akoundal@xxxxxxxxx] 
Sent: Wednesday, March 21, 2018 3:46 PM
To: Kris Davis <Kris.Davis@xxxxxxx>
Cc: fio <fio@xxxxxxxxxxxxxxx>
Subject: Re: FIO latency bin midpoint vs upper limit capture

Hi Kris,
I am mentioning for the bins that get generated in the json+ fille or the clat_hist files. Clat_hit still has all the bins listed even if they are empty while JSON+ now just fills/reports which are being seen for a given run.

FIO 3.1+.
bins
6816 = 1  ==> 6816ns  1 IOP took.
7817 = 10 ==> 7817ns 10 IOP took ..
.......

FIO2.18
bins
0 = 1  ==> 1us 1 IOP took
1 = 50 ==> 2us 50 IO took
......
1216 = x

When the tool reports the IOP completion latency for the given bin, it will report it as the "median" value of time not the "max" value of the time. So when you are plotting or reporting the data that is not the "max" value of the latency for that reported bin.

This will result in two things:
1) multiple runs on the same workload config will have deviations .
2) higher deviation will be observed for the 5-9s + if you use the "max" value wrt to "median".

I hope this helps in clearing the things and clear the confusion.

On Wed, Mar 21, 2018 at 12:17 PM, Kris Davis <Kris.Davis@xxxxxxx> wrote:
> I'm sorry, I don't think I'm on the same page...  Are you referring to the latency percentages given in the summary output, or the latency log files, or the clat hist log file?
> Thanks
>
> Kris Davis
> Western Digital Coporation
> Email: kris.davis@xxxxxxx
> Office:: +1-507-322-2376
>
> -----Original Message-----
> From: abhishek koundal [mailto:akoundal@xxxxxxxxx]
> Sent: Wednesday, March 21, 2018 2:00 PM
> To: Kris Davis <Kris.Davis@xxxxxxx>
> Cc: fio <fio@xxxxxxxxxxxxxxx>
> Subject: Re: FIO latency bin midpoint vs upper limit capture
>
> That is how the tool does by default unless it has been changed in the 3.0+ versions where there are no bins but  completion time vs iops landing in that zone.
> If I recall prior to 3.0, it was bins -> 0 , 1 ...12xx.
>
> On Wed, Mar 21, 2018 at 10:59 AM, Kris Davis <Kris.Davis@xxxxxxx> wrote:
>> What are you doing to see a "report" of the mid latency?
>>
>> Kris Davis
>>
>> -----Original Message-----
>> From: fio-owner@xxxxxxxxxxxxxxx [mailto:fio-owner@xxxxxxxxxxxxxxx] On 
>> Behalf Of abhishek koundal
>> Sent: Wednesday, March 21, 2018 12:55 PM
>> To: fio <fio@xxxxxxxxxxxxxxx>
>> Subject: Re: FIO latency bin midpoint vs upper limit capture
>>
>> Checking back if there is any feedback on the above request for reporting max latency in the bins.
>> Appreciate the support.
>>
>> On Wed, Mar 14, 2018 at 2:07 PM, abhishek koundal <akoundal@xxxxxxxxx> wrote:
>>> All,
>>> Currently the FIO latency  bins does the i/o count and but then as 
>>> per Lower bound, midpoint (rounded off), upper limit
>>>
>>> The reported latency is the based on the "midpoint".
>>> Is there a way to report it based on the "upper limit"? e.g. compile 
>>> fio with some switch etc.
>>>
>>> Appreciate your support always :).
>>>
>>> --
>>> Life is too short for silly things so invest your time in some 
>>> productive outputs!!
>>
>>
>>
>> --
>> Life is too short for silly things so invest your time in some productive outputs!!
>> --
>> 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
>
>
>
> --
> Life is too short for silly things so invest your time in some productive outputs!!



--
Life is too short for silly things so invest your time in some productive outputs!!
��.n��������+%������w��{.n�������^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�

[Index of Archives]     [Linux Kernel]     [Linux SCSI]     [Linux IDE]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux