Monitoring Transfers With hIOmon's Disk I/O Ranger
With ASU behind us, we dive into hIOmon, which helps rate the performance of file transfers and application installations using a “Data Transferred/Time Index (DXTI).” This gives us a high-level means for comparing I/O performance. A higher index corresponds to better performance (more data transferred and/or lower response time).
The hIOmon DXTI is calculated by taking the observed amount of data transferred, using the I/O operations converted to megabytes for scaling, and dividing by the combined sum of the actual response times of those same I/O operations. What you end up with is a lot like a car's fuel economy index insofar as it conveys performance efficiency. It is comparable to more miles driven (more data transferred) for fuel used (response time taken to transfer this data). Or, it could represent the same number of miles driven (data transferred) using less fuel (lower response time).
This software can be configured to monitor at the physical volume level, located between the file system and the volume manager. This gives us an indication of I/O performance below the file system and closer to the storage device within the constraints of the operating system.
The procedure we run through goes as follows:
- Copy MP3 files: 47 695 MiB written (6663 files in 353 folders).
- Copy Windows image backup: 14 875 MiB written (16 files in four folders).
- Copy Windows 7 SP1 ISO file: 1953 MiB written
- Install Crysis: 2103 MiB written
- Install Office: 1174 MiB written
- Back-up Steam game: 14 246 MiB written
- Run antivirus scan: 365 MiB read
- Play Crysis single-player: 813 MiB read
Due to the dynamic nature of Windows' file system, there can be some variation in the exact I/O activity from one run to the next. However, the observed I/O activity was very close, and slight variations do not make a different to the DXTI results in the case of the tasks being monitored.
We used OCZ's Vertex 4 as the source drive for our transfers, monitoring each task separately and stopping to record results before moving on to the next one.
Plextor's M5S dominates the Crucial m4, and generally performs similarly to Samsung's 830.
Let's take a closer look at some of the numbers behind the DXTI results. In our first example, we look at the statistics involved in generating the score for our Copy Windows image backup task.
|Copy Windows Image Backup||Crucial m4||Plextor M5S||Samsung 830|
|Write IOs||15 219||14 953||14 954|
|Write Data (MiB)||14 857||14 858||14 858|
|Avg Rsp Time (ms)||3.614||2.491||2.379|
|Max Rsp Time (ms)||10.837||79.432||18.243|
|% Rsp Times < 1 ms||1.3||0.46||0.5|
|Rsp Time 1 < 10 ms||13 806 (90.72%)||14 714 (98.4%)||14 829 (99.16%)|
|RSP Time 5 < 10 ms||1200 (7.88%)||56 (0.37%)||30 (0.2%)|
|Rsp Time 10 < 100 ms||15 (0.1%)||114 (0.76%)||20 (0.13%)|
|QD > 1||365 (2.4%)||137 (0.92%)||134 (0.9%)|
The m4's DXTI is significantly lower than Plextor's M5S and Samsung's 830. I've highlighted the numbers responsible for this result. As you can see, the m4's average response (Rsp) time is higher than the M5S or 830, with 1200 I/Os occurring in the 5-10 millisecond bracket.
Plextor's drive fields more I/Os within the 5-10 ms range than Samsung's 830 (along with more in the 10-100 ms range as well), claiming a second-place finish.
In our second example, we look at the Back-up Steam game task.
|Back-up Steam Game||Crucial m4||Plextor M5S||Samsung 830|
|Write IOs||14 650||14 651||14 609|
|Write Data (MiB)||14 247||14 247||14 246|
|Avg Rsp Time (ms)||3.915||2.44||2.291|
|Max Rsp Time (ms)||611.13||103.68||3.263|
|% Rsp Times < 1 ms||2.53||2.46||2.27|
|% Rsp Times 1 < 5 ms||12 424 (84.81%)||14 161 (96.66%)||14 277 (97.73%)|
|RSP Time 5 < 10 ms||1848 (12.61%)||33 (0.23%)||0|
|Rsp Time 10 < 100 ms||31 (0.21%)||96 (0.66%)||0|
|Rsp Time 100 < 500 ms||2 (0.01%)||1 (0.01%)||0|
|Rsp Time 500 ms and >||1 (0.01%)||0||0|
|QD > 1||137 (0.94%)||134 (0.91%)||51 (0.35%)|
Again, Crucial's DXTI is significantly lower than either the Plextor M5S or Samsung 830. And again, the offending results are highlighted in bold text.
The m4's average response (Rsp) time is highest due to the number of I/Os occurring in the 5-10 ms response time range. Things even get nastier for the m4, though, as one I/O takes 611.13 ms to complete.
Plextor's M5S incurs a maximum response time of 103.68 ms, which, combined with its higher percentages of IOs completed in 5 ms or more, results in another loss to Samsung's 830.
In our third example, we look at the statistics for the Office Installation task.
|Office Installation||Crucial m4||Plextor M5S||Samsung 830|
|Write Data (MiB)||1174||1180||1174|
|Avg Rsp Time (ms)||3.732||1.508||1.588|
|Max Rsp Time (ms)||27.336||79.538||16.957|
|% Rsp Times < 1 ms||29.52||61.52||63.12|
|% Rsp Times 1 < 5 ms||2269 (42.21%)||1652 (31.77%)||1551 (28.82%)|
|RSP Time 5 < 10 ms||1064 (19.79%)||299 (5.75%)||275 (5.11%)|
|Rsp Time 10 < 100 ms||456 (8.48%)||41 (0.79%)||159 (2.95%)|
|QD > 1||4390 (81.66%)||3932 (75.62%)||4087 (75.94%)|
Plextor's M5S comes out on top this time, achieving the lowest average response time and lowest number of I/Os in the 10-100 ms tier. Meanwhile, Crucial's m4 incurs the highest percentage of response times above 1 ms.
When you take into consideration the fact that Plextor's M5S isn't even supposed to be the company's fastest product, it performs exceptionally well in the real-world tasks we tracked.