Sustained 4K Random Write Table Empty
coolrecep opened this issue · comments
I don't know if this should be filled or not but the sustained 4K random write table is empty:
The latency #s are not being read correctly on your OS for some reason. My gut tells me this is related to your locale, and there being something in the PS1 expecting a "." where there's a "," for decimal point.
Can you ZIP up the whole test directory and attach it here so I can double check this, and have some real output to test any updates against.
Here it is, with the results file:
Just got back from some time off and catching up with this. The ZIP file you attached only has the .ODS file. I need the raw FIO outputs, if you still have them, as by the time it hits the ODS it's bad. Can you just ZIP the entire test directory w/subdirs (details_*)?
The process used by the script is to run FIO and dump results to a file, read that file and parse it, then combine it with the raw ODS file. By the time there's an ODS it's too late to look at anything, the parsing stage is where things seem to be barfing.
Thx,
-EFP3
Ping on this, if you still have the full directories so I can see whether it's FIO or PowerShell messing up the locale stuff. Thx!
Hi, I've been doing quite a lot of benchmarks for a project and encontered the same issue reported by @coolrecep.
I have also found an issue when running ezfio under linux, the ods files are not being generated. The .ods you find in the attachment (under the linux directory) were generated by hacking up the powershell function used by ezfio and forcing it to parse the linux .csv files.
Fio.tar.gz
Thanks a ton for the failing files! I'll look at them later today.
Let me make sure I understand your problems. May want to open another bug to track if they're two different things to help tracking.
So under Windows you're seeing @coolrecep 's problem, or is it under Linux? And do you have any Windows runs you can ZIP up that have the same missing-values problem (or are they in the tar.gz file which is an odd thing to find Windows files in)?
And the Linux runs are going to completion and not generating anything in the ODS as well?
Thanks!
All the linux/windows results are in the attachment. The linux runs do not generate an .ods file, however, the benchmarks complete successfully.
The windows runs display the same behavior as @coolrecep reported.
EDIT: The linux runs complete, the problem seems to be with parsing the .csv files.
Thanks for the info. I've gone through the Windows runs and see a file that's not quite working:
Windows10\vmware\local\test5\details*\TestRand_w100_bs4096_threads64_iodepth1_PhysicalDrive1.out
FIO is using C-Locale, I think, so decimal separators are "."s. Are you running on a locale which uses "," instead of "." as the decimal point? If so, what is it?
I ran the following snippet which is basically cut-n-pasted from the .ps1 file and get the proper answer (433.5). I'll investigate if there's a way to change the [float] conversion locale to support FIO's lack of locale...
$testfile = "Fio\Fio\Windows 10\vmware\local\Test5\details_34GB_4cores_3408MHz_PhysicalDrive1_DESKTOP-C5D13EU_2016-11-28_17-10-57\TestRand_w100_bs4096_threads32_iodepth1_PhysicalDrive1.out";
$results = (Get-Content $testfile | Select-Object -Last 1).Split(";")
$wlat=[float]$results[80]
$rlat=[float]$results[39]
$lat = "{0:F1}" -f ([math]::Max($rlat, $wlat))
echo $lat
output from systeminfo.exe:
System Locale: pt;Portuguese (Portugal)
Input Locale: pt;Portuguese (Portugal)
and ... there's this (check LC_NUMERIC).
Yes, that's the problem. Your locale expects a "," while FIO is ignoring your system locale and producing C locale "." output.
I'll open a bug in the FIO tracker, you may want to follow it.
I just pushed a branch "locale" with a simple hack to replace the hardcoded "."s in FIO's outputs with system locale-dependent decimal points.
Can you check it out ( git clone -b locale https://github.com/earlephilhower/ezfio.git ) and try? I'm unable to change my system locale on my work machines.
OK. Finally performed a test with both RAID 960 PRO NVME and single 512 GB.
Please take a look.
Howdy,
Thanks for the full ZIP file. The ,/. problem is fixed, but there's another one that's only seen on a localized Windows version (which I don't have)...the titles of performance counters are localized as well. The data's collected properly in the PerfMon log file, but it is not being seen by the script.
Basically, for English-language Windows CSV files, they have a column called "reads" and "writes" which are then filtered by PowerShell using those words.
For Turkish, it looks like "Okuma" and "Yazma" are the translations, so the script can't find the "read" or "write" column and gives up.
What is doubly strange is that when I create the Performance Counters, I use the English language "Reads/s" and "Writes/s" strings and it works fine even on your Turkish Windows.
I'll have to dig around and see if PerfMon guarantees the order of columns. If so, then replacing "The 'reads/s' column" with "the 1st column" is a very straightforward fix.
Thx
-EFP3
I am glad to contribute. Thanks.
I've just pushed a version of the script which uses the column index and not the name to identify reads and writes for the timeseries data. Can you give that a try?
Thx
-EFP3
I will but it will take "some" time :)
No problem. I've already checked that it doesn't break US English Windows, and even if the order of columns is different I add the reads+writes together so it doesn't really matter as the sum will be the same.
Closing due to inactivity. If this appears again, please let me know. Thanks! -EFP3