hIOmon SSD Performance Monitor - Understanding desktop usage patterns.

[overthere]

In post #221 Anvil provided a hIOmon Presentation Client screenshot that showed various metrics collected during an ATTO Disk Benchmark run upon his 9260 array. Here are some considerations and further observations that might be of interest:

Consideration A: Certain metrics shown within the hIOmon Presentation Client display reflect an average calculated for either the latest Observation period (or an overall average calculated for the time period since the start of the first Observation period up until the end of the latest Observation period).

For example, the Read IOPS value of 3552.4 (as shown within the screenshot) is simply the total Read I/O operation count (1 066 249) divided by the time duration of the latest Observation period (5 minutes and 0.1453561 seconds, i.e., 300.1453561 seconds), which was the only Observation period (so far).

So basically what the Read IOPS represents is the average IOPS rate over the course of the Observation period (i.e., an average of 3552 read I/O operations per second during the 5 minute Observation period).

Of course, the ATTO benchmark performed read I/O operations at varying transfer sizes (and accordingly varying IOPS rates) during the overall benchmark test period. In any case, the hIOmon Presentation Client calculates/reports the average IOPS rate based upon the time duration of the particular Observation period.

One might also have noticed that the last read I/O operation completed approximately 1 minute and 6 seconds before the end of the 5 minute Observation period (and so if this 1 minute and 6 second time duration, within which no read I/O operations were performed, were excluded from the average read IOPS calculation, then the calculated average read IOPS value would be greater than the 3552.4 IOPS value).

The hIOmon Presentation Client calculates the "average" IOPS value in this manner so that users can perform, for instance, various capacity planning and performance analysis studies over extended time frames (e.g., to identify those particular time periods of intense and/or low I/O operation activity.

Please note that the length of an "Observation period" is essentially the user-specified periodic time interval for which the hIOmon software can be configured to collect the summary I/O operation performance metrics for display, export, etc.

As an alternative to collecting summary I/O operation performance metrics upon a user-specified periodic basis, the hIOmon software can also be configured to collect the summary metrics for offload either when the respective file is closed and/or upon an "alert" basis (i.e., when a user-specified threshold - for instance, some maximum read I/O operation response time value, some total amount of write data transferred, etc. - has been detected/observed by the hIOmon I/O Monitor for the respective file).

Consideration B: The hIOmon "SSD I/O Performance Analysis" script option configures the hIOmon software so that I/O operation activity performed by any process will be included within the summary I/O operation performance metrics that are collected.

Consequently, the collected summary metrics displayed by the hIOmon Presentation Client (as shown within the screenshot) might include I/O operations that were performed by processes other than the ATTO benchmark program. These processes could include system processes that update various file system metadata (which can occur since the read and write I/O operation activity performed by the ATTO benchmark tool is directed to a file).

In any case, the actual amount of I/O operation activity performed by such processes is likely negligible (especially since the bulk of the I/O operation activity was due to the ATTO benchmark program and granted that there was no other appreciable I/O operation activity performed by other processes, such as an antivirus program, directed to the logical drive that was the target of the ATTO benchmark program). However, any such I/O operation activity that is extraneous to that performed directly by ATTO can skew (however slightly) the reported metrics from those expected to be attributable to the ATTO program alone.

Consideration C: I configured the hIOmon software to take a closer (although still very cursory) look at how the ATTO Disk Benchmark actually performs its "benchmarking" I/O activity.

One thing that I first noticed is that ATTO begins by first generating (i.e., writing) its "benchtst.$$$" test file. If the selected value of the ATTO "Total Length" option is 2GB (as in the case of Anvil's screenshot), then ATTO will generate/write a 2GB test file using 256 write I/O operations each with a data transfer length of 8388608 bytes, which happens to be the largest "write I/O operation" data transfer size shown with the hIOmon Presentation Client screenshot and also the largest selectable ATTO "Transfer size" option value.

Incidentally, it appears (based upon the I/O operation performance metrics that I collected using hIOmon) that if you select an ATTO "Total Length" option value smaller than 8MB (technically 8MiB), then ATTO will nevertheless write out an initial test file that is 8 MiB in size.

Anyway, some of the key points here are: (1) ATTO always starts out by generating/writing its test file - so there is some initial write I/O operation activity performed by ATTO before it actually begins its various "transfer size" I/O operation activity, which is the basis of its "advertised" benchmarking; and (2) the write I/O operation activity by ATTO that occurs when initially generating its test file is included within the "Write I/O operation" metrics collected/shown within Anvil's hIOmon Presentation Client screenshot.

Consideration D: Based once again upon my collection of I/O operation performance metrics using hIOmon, I noticed that ATTO apparently performs varying amounts of read (and write) I/O operations. The difference between successive ATTO runs was sometimes on the order of thousands (e.g., between 10 000 and 20 000 overall total read I/O operation count difference between successive ATTO runs). Perhaps this difference is due to some system-dependent phenomenon. In any case, please note that I configured the hIOmon software to collect summary metrics for the "benchtst.$$$" file only and only for the ATTO "bench32.exe" process (using ATTO Disk Benchmark version 2.46).

This read and write I/O operation variance is disconcerting to me (at least based upon my working with folks defining benchmarking standards). To my understanding, one of the tenets of sound benchmark design is the "consistent repeatability of the stimulus". In other words, the benchmarking tool should perform the same prescribed activity each time the benchmark tool is run using the same configuration options (otherwise it is difficult to perform, for example, an "apples-to-apples" comparison).

Consideration E: The ATTO benchmarking tool does not necessarily read (nor write) the entire "Total Length" for (at least) the 512 byte transfer size. This in evident in Anvil's hIOmon Presentation Client screenshot. For a transfer size of 0.5 KiB and a "Total Length" of 2 GiB, a total of 4 194 304 sequential read I/O operations (each with a data transfer size of 512 bytes) would be required to read the entire 2 GiB test file.

As shown in Anvil's screenshots, ATTO was configured to include a transfer size of 0.5 KiB. The hIOmon Presentation Client shows the smallest read data transfer size of 512 (along with a maximum read data transfer size of 8 388 608 - which confirms that the ATTO "Transfer size" span that Anvil specified was in fact performed). However, the hIOmon Presentation Client shows an overall total of 1 066 249 read I/O operations were performed; as noted above, 4 194 304 sequential read I/O operations would be required to read the entire 2 GiB test file for a 512 bytes data transfer size alone. Anvil might have been pointing this out with his highlighting of portions of the hIOmon Presentation Client screenshot.

[Ao1]

OK, now I try to draw some conclusions for discussion. Please bear in mind that I discuss typical desktop usage patterns, which are relatively undemanding.

From what I have been able to observe Raid 0 has made no noticeable difference to the speed of applications, but I have never understood why. Also a lot of people have reported no observable difference between different brands of SSD, when some are technically faster than others.

The only real differences that I have noticed between SSD & HDD is boot up, responsiveness immediately after boot up and the way applications open instantly. I guess game loading is also faster, but I can't say game playing is any different. (I only play COD, so maybe there are exceptions).

The impact of system file cache has been a revelation for me, but thinking about it more the access times for HDD are so high that you would be waiting forever for anything to happen unless the system file manager could speed things up.

The system file manager seems to do a very good job at making things run fast without putting a load on the device or deferring the load to reduce impact. In instances where the system file manager cannot cope with the demand the speed of the device becomes the determining factor.

For arguments sake if it was assumed that the system file manager could deal with 80% of I/O demand by either bypassing or deferring load to the device the remaining 20% of I/O's are when you would see the performance penalty of the HDD in comparison to SSD. The higher the load (like bootup) the slower things get as they end up being dealt with by the device. With SSD you can get around 98% fast IOP counts. With raid it goes up to around 99% but it seems it does this via more effective cache management not via faster speeds from the device. This would change under heavier loading, but for typical desktop use the demand is not sufficient to see the benefit of the array device speed.

Below I capture typical use and isolate the device speeds in raid 0 and raid 1. I'm not using anything like the available sequential read speeds and I copied over a couple of large files, which should have been a lot faster. When I get time I will do the same for a single device to compare.

Assuming I'm on the right track this makes me wonder why you need a raid array to give you more/ better managed system cache. It would seem that with more/ better managed system cache an SSD's overall performance could be a lot better for desktop use.

Next up I'm going to drop down to 2GB of RAM (from 8GB) and under clock it to see the impact on the storage performance. I'm also trying to think of a way to see if the system file manager is actually slowing down SSD performance in some instances.

[saint-francis]

Ao1, what you are doing here is the most interesting and important SSD work I've seen in probably a year or more.

[Ao1]

Thanks for the feedback.

[Anvil]

Hi Overthere
I've been swamped with a head cold and so I haven't read all of your analysis, will do later tonight.
I did notice that the number of I/Os seemed low compared to what one would expect, it might just do a "sample" number of I/Os, I'll redo the test using a smalller testfile just to see what happens.
It's not an issue as long as ATTO is performing the same number of IOs for that exact testfile size, or it might just be that ATTO isn't built for SSD speeds

Ao1,
Your assumption about the SSD (most SSDs) isn't exactly stressed while doing normal desktop tasks is as expected, the X25 is not even close to being stressed.
At the same time, there is a difference between SSD controllers, application loadtime can differ quite a lot, you should have had a SF or C300 to compare with the Intel

The difference between single drives and raid should show up once the task is starting to stress the SSD controller.
You could try monitoring an AS SSD run using sinlge, raid-1 and raid-0.
AS SSD, being a synthetic benchmark would of course not reflect normal desktop usage but it will show when there is a point in adding an extra SSD for more throughput/iops.

My VM tests does show improvement going from a single drive to raid, at the same time the number of seconds used by storage compared to the runtime length shows that most of the time the SSD is just waiting.
(meaning there are now other bottlenecks in the system)

[Ao1]

Here I use Cacheman 7 to manage the file cache system. I've only tweaked a few settings, but already there are some noticable improvements.

[overthere]

...I did notice that the number of I/Os seemed low compared to what one would expect, it might just do a "sample" number of I/Os, I'll redo the test using a smalller testfile just to see what happens.
It's not an issue as long as ATTO is performing the same number of IOs for that exact testfile size, or it might just be that ATTO isn't built for SSD speeds

Hi Anvil,
I believe you are right that "it's not an issue as long as ATTO is performing the same number of IOs for that exact testfile size..." - although I suspect many/most folks might assume that the total number of I/O operations to be performed will be the exact number required to access the entire testfile size (presumably once) as indicated by the selected "Total Length" value.

In any case, a variation between ATTO runs in the total number of I/O operations (for the same given "Transfer Size" and the same associated testfile size) means, of course, a variation in the total amount of data transferred for the particular "Transfer Size" test.

And varying the total amount of data transferred under such circumstances (i.e., given the same transfer size and testfile size) in a benchmark test whose focus is on "data transfer throughput" (specifically "maximum sequential MB/s") seems suspect to me.

I can see that in those cases where a larger testfile size (e.g., 2 GiB) is selected, ATTO might want to reduce the total number of I/O operations performed (and correspondingly the amount of data transferred) for the smaller "Transfer Sizes" so as to help reduce the overall time required to run the benchmark test.

But, as I think that you would agree, such a reduction in the total number of I/O operations performed should be consistent (i.e., the same) between ATTO runs.

Hi Ao1,
Sorry that I have not yet replied to your post #222; I have already looked over the post and have several comments in mind, which I hope to get posted sometime later today.

[overthere]

In post #222 Ao1 chose a good scenario/example that can help illustrate some of the dynamics involved with the operation of the "system file cache" mechanism within the Windows OS:

To better understand the three monitoring levels I thought a “simple” file copy would help elaborate what happens where and when. ...

E drive is static data only. The Test File is 731,082,752 bytes.

The copy/ delete/ copy process was done as follows:
• Copy file (right click) Test.avi from E:\Test File to E:\ (paste)
• Move copied file to recycle bin (right click, delete)
• Re paste file to E:\ (right click paste)

The above was carried out within a minute, but interesting it would appear that reads and writes generated by the file transfer occurred sometime later on the actual device, but back to that later.

I like the diagram from the TechNet article as it shows the flow of data. If I use that diagram to try and understand what is happening from the monitoring results below:

All uncoloured entries are activities occurring between stages 1 and 5.

The TechNet diagram that Ao1 mentions (and which is also included within his post) basically reflects the case where the data to be accessed by a file read I/O operation is not presently located within the system file cache and so must first be retrieved from the actual storage media (i.e., the physical disk device).

This case/diagram is the second scenario/diagram shown amongst the three diagrams that Ao1 included within his prior post #203, where the first TechNet diagram is the case in which the data to be transferred by the file read I/O operation is present within the system file cache (i.e., a "system file cache read hit") and the third TechNet diagram is the case where the data written to the system file cache is subsequently (at some later time) written/transferred out to the actual storage media.

It is important to note that the file "copy / delete /copy" example chosen by Ao1 actually involves all three of these TechNet cases/diagrams and not simply the second diagram alone/only. This can be substantiated by the summary I/O operation performance metrics that were collected by hIOmon and which are included/shown within Ao1's post.

For example, the "system file cache read hit" I/O operation count can be derived by subtracting the hIOmon "ReadSystemCacheIOPmissCount" metric value from its associated "ReadSystemCacheIOPcount" metric value. The hIOmon "ReadDataXferSystemCacheHit" metric value shows the corresponding amount of data transferred from the system file cache for the "system file cache read hit" I/O operations. In any case, these metrics reflect those read I/O operations that fall into the TechNet diagram/scenario number one.

Similarly, the hIOmon "ReadSystemCacheIOPmissCount" and the "ReadDataXferSystemCacheMiss" metric values can be associated with the second TechNet diagram. In addition, the hIOmon "PhyDev Read Data Xfer" metric can generally be associated with the retrieval of the data from the actual physical device in the case of a "system file cache read miss" scenario (i.e., the second TechNet diagram).

Finally, the hIOmon "WriteSystemCacheIOPcount", the "WriteDataXferSystemCacheHit", and the "PhyDev Read Write Xfer" metrics can be associated with the third TechNet diagram (where the data associated with file write I/O operations performed as a result of the "file copy" actions are first written to the system file cache and then subsequently transferred to the actual storage media).

As an aside, unhiding the hIOmon "Read IOP Count" metric column within the displayed hIOmon metrics table might be helpful for the sake of completeness.

One other brief comment here. Folks will likely notice several occasions where there are multiple rows with the same file name and same time period within the displayed hIOmon metrics table. This is due to the "multiple opened instances" of the same file (as briefly described within my prior post #219).

I suspect that these multiple instances of the same file are related to processes such as Windows Explorer (e.g., performing the actual copy of the file), the System process (which can be involved with "pre-fetching" portions of the file into the system file cache and also with subsequently writing out the file from the system file cache to the storage media), and perhaps an Antivirus program (such as Microsoft Security Essentials) that are (concurrently) accessing the same file. Please note that the names of those specific processes involved with a particular instance of a file are included amongst the summary I/O operation metrics collected by hIOmon for the particular file instance.

This post is already getting a bit long, so I'll defer my other comments to another subsequent post.

[overthere]

Continuing from my prior post #233 in regards to Ao1's post #222:

Assumptions:
• Performance in these stages is down to the OS and RAM. Nothing is occurring on the device.
• The system cache IOP miss counts are page faults from RAM, which then require a re-read from the file system.
• Most of the Read/ Write FastIOPcounts are done in cache and when this happens there are independent of the device speed. If I look at the results from post #48 it is likely that the 87.6% FastIOPcounts with HDD were predominantly achieved by cache. The SSD managed 100% because the speed of the SSD was such that it could satisfy non cached read IOP counts in less than a millisecond. [Edit] So it seems activities from 1 to 5 are designed to mitigate the slow speed impact of a HDD. I wonder if the file system driver/ cache manager could be better optimised for SSD. (?)

Performance throughout the TechNet diagram/scenario number one (i.e., system file cache "read hit") is essentially related to that of the OS and RAM, with the actual device not being a factor within this scenario.

Performance in the case of the TechNet diagram/scenario number two (i.e., system file cache "read miss") is also essentially related to that of the OS and RAM, with the device only becoming a factor when a system file cache read miss actually occurs (since the data for the read I/O operation must then be retrieved from the actual storage media).

The set of "SystemCache" summary I/O operation performance metrics collected by the hIOmon software reflects those I/O operations that explicitly requested the use of the "system file cache"; moreover, these I/O operations are handled by means of an expedited path through the OS I/O stack.

The hIOmon software considers an I/O operation to be a "system cache hit" when the I/O operation, as observed by the hIOmon I/O Monitor, was successfully performed using the "system file cache" by explicit request and which completed within less than one millisecond.

Similarly, "SystemCache" I/O operations that completed within one or more milliseconds are regarded to be "system cache misses" and are considered to have incurred an I/O operation directed to the corresponding actual device.

It is also imporant to note that:

1. Those I/O operations that are identified by the hIOmon I/O Monitor as "Fast I/O operations" include both the "System Cache Hit" I/O operations (as described above) as well as those I/O operations that did not explicitly request the use of the "system file cache" but which nevertheless completed in under one millisecond.
   
   
2. "Fast I/O operations" that do not explicitly request the use of the "system file cache" can nevertheless be satisfied by the system file cache under the direction of the OS. That is, there can be I/O operations that complete in less than one millisecond (and so are considered to be "Fast" I/O operations) that the OS satisfied by using the system file cache even though these I/O operations did not explicitly request the use of the system file cache.
   
   
3. "Fast I/O operations" also include those I/O operations for which there was no system file cache involvement but which neverthesless completed in less than one millisecond; these I/O operations can include physical volume and/or physical device I/O operations.

In regards to the FastIOPcount metric values shown in post #48, I am not sure whether the metrics shown were collected by hIOmon at the file level (i.e., logical disk level) or at the physical volume or physical device level.

In any case, HDD physical volume (or physical device) I/O operations that are observed by hIOmon to be "Fast I/O operations" are often the result of caching further down the I/O stack (e.g., a cache upon a RAID controller card, a cache upon the device itself, etc.). SSDs are, of course, another matter given their inherent fast read access times as Ao1 mentioned.

\Device\HarddiskVolume3 is when data actually gets read and written to the device. I assume stage 7 - Disk Driver.

Assumptions:
• This is when the speed of the device counts, however when this actually occurs is typically “after the event”. The speed of the device only therefor counts if it is a direct read/ write that bypasses the cache manager. (Assuming no further load when the read/ write occurs)

The I/O operation performance metrics collected by hIOmon at either the physical volume level (e.g., \Device\HarddiskVolume3) or the physical device level within the OS do reflect data that is actually transferred with the storage media proper.

This is where the performance characteristics of the storage media (along with the other components along the I/O operation path, e.g., the transport interface type, HBA, etc.) especially come into play and can have a significant impact upon the overall performance of the I/O operation.

Please note that the "speed" of the device (and the other elements down the path to the device) is a factor not only in the case of "system file cache misses" (i.e., how quickly the data can be retrieved to satisfy a file I/O operation that encounters the system file cache miss), but can also be a factor in anticipatory pre-fetching by the OS into the system file cache.

That is, the "faster" the OS can pre-fetch the data from the device, then presumably the more likely that the data will already be resident within the system file cache when a subsequent file read I/O operation is performed to retrieve this pre-fetched data. Of course, there are also a number of other factors to be considered in such a scenario (e.g., the extent to which the file I/O operations are sequential read I/O operations, the concurrent I/O activity of other, perhaps competing processes/applications, etc.) along with a slew of other caching, system, and resource issues.

E: is a summary of all activity within stages 1 and 7

Assumptions:
• This is showing all activity be it in cache or on the device.

The hIOmon software can be configured to collect "summary" I/O operation performance metrics upon an individual device basis.

In the case of a "device summary" for a logical drive/disk (e.g., E:), the summarized I/O operation performance metrics represent the sum of the performance metrics for all of the files being monitored by the hIOmon I/O Monitor for the specified logical disk.

That is, the "Device Summary" for the logical disk represents the overall aggregate of all summarized I/O operation metrics for all files (and only those files) that were being monitored by the hIOmon I/O Monitor and which reside upon the respective device.

Also please note that the "Device Summary" reflects cumulative metrics that have been collected by the hIOmon I/O Monitor since it began (or re-started) monitoring I/O operations for the respective device.

In contrast, the summary I/O operation performance metrics that are collected by the hIOmon I/O Monitor upon a periodic basis for files reflect only those I/O operations that were observed by the hIOmon I/O Monitor during the duration of the corresponding summary time period (e.g., if the summary metrics are being collected upon a "one minute" periodic basis, then the summary metrics reflect only those I/O operations that were observed during the respective one-minute period).

In any case, the "Device Summary" metrics for a logical device include both "SystemCache" and "PhyDev" I/O operation performance metrics for those monitored files associated with the logical device.

\Device\HarddiskVolume3:\<DASD>\VMMFrom previous posts this has been explained as “system flags associated with the I/O operation indicate involvement by the system “Virtual Memory Manager (VMM)”.

Assumptions:
• Entry 21 is why the re-paste appeared to be instantaneous. It was copying data from the VMM to the file system driver. The actual read/ write on the device occurred a minute later.

Entry 21 within the hIOmon metrics table is certainly a key entry. It shows not only the data read from the device (Read Data Xfer), including that for the "E:\Test File\Test.avi" file to be copied (some of which was copied into the system file cache) but also the data written to the device from the system file cache (Write Data Xfer), including both times the file was copied.

In addition, entries 33 and 36 show the copied file being written to the system file cache (q.v., WriteSystemCacheIOPcount and WriteDataXferSystemCacheHit) and written to the device (PhyDevWriteDataXfer).

[Anvil]

Overthere

I've performed a few more tests using ATTO and there is definately something strange going on

First I tried 2 runs using 512B only, one run using 256MB testfile and the next run using 512MB.
Here are the results of those two runs
atto_512B_256MB_vs_512MB_testfile.png

As you can see, the one thing that differs is Write I/O.
(mainly due to the size of the testfile)

--

Finally I ran the full range (512B-8192KB) using a 256MB testfile
atto_full_256MB_testfile.PNG
I haven't compared it to the 2GB testfile run yet.

[overthere]

Overthere

I've performed a few more tests using ATTO and there is definately something strange going on

First I tried 2 runs using 512B only, one run using 256MB testfile and the next run using 512MB.
Here are the results of those two runs
atto_512B_256MB_vs_512MB_testfile.png

As you can see, the one thing that differs is Write I/O.
(mainly due to the size of the testfile)

--

Finally I ran the full range (512B-8192KB) using a 256MB testfile
atto_full_256MB_testfile.PNG
I haven't compared it to the 2GB testfile run yet.

Hi Anvil,

Thanks for running the additional ATTO tests.

Several items immediately come to mind when comparing the two 512B runs (i.e., the one with the 256MiB testfile size and the other with the 512MiB testfile size):

I believe that you are right about the additional write data transferred (for the 512MiB testfile) being attributable largely to the increased testfile size. Adding the additional 268 435 456 bytes (incurred when ATTO initially wrote out the 512MiB testfile, in comparison to the 256MiB testfile, before performing the actual benchmarking tests) to the 329 531 392 (i.e., the total write data transferred for the 256MiB testfile) gets you into the ballpark of the total write data transferred amount for the 512MiB testfile (with the actual sum of the two being 597 966 847, and keeping in mind that there is also a small amount of other extraneous read and write I/O operation activity occurring in the background due to, for instance, file system metadata I/O operations).

Now the writing of the additional 256MiB for the 512MiB testfile required an additional 32 write I/O operations (assuming a write data transfer size of 8 388 608). So if you subtract these additional 32 write I/O operations from the grand total of write I/O operations (119 097) for the 512MiB testfile, I believe you get a total of 119 065 - which is less than the grand total of write I/O operations (119 069) for the 256MiB testfile size!

It seems then that ATTO did not even touch the upper 256MiB of the 512MiB testfile (especially since it is performing sequential I/O operations with each transfer size test beginning at zero).

And the same pretty much applies to the read I/O operations (i.e., the 512MiB testfile had only 1 000 more read I/O operations than the 256MiB testfile, which of course was one-half the size of the 512MiB testfile).

BTW, the difference in the total read data transfer amounts for the 256MiB testfile and the 512MiB testfile runs is 512 000 bytes (which just so happens to be the 1 000 read I/O operations of 512B each).

Regarding the comparison of the full range (512B-8192KB) using a 256MiB testfile run with the 2GB testfile, are you referring to your prior run shown within your prior post #221?

If so, that prior ATTO run used your 9260 array, in which case did you also use the same 9260 array for your full range / 256MiB testfile run above?

In any case, it appears that your latest full range / 256MiB testfile run shows a rather balanced total amount of read and write I/O operations (and, of course, total amounts of data transferred - about 33GB each).

But your prior 9260 full range / 2GiB run not only shows an "imbalanced" total amount of data transferred (about 41GB read to 57GB write), it also seems that the increased testfile size (which is 8 times as large) only increased the amount of data actually transferred by a relatively small percentage.

I am not suggesting that there necessarily should be 8 times more data transferred (or 16 times total for both read and write combined) for the 2GiB testfile size, but I am not sure in any case what scaling factor is used by ATTO for the various testfile sizes.

Yep, but there does appear to be something strange going on ...

[Ao1]

Here I capture metrics using the WMI Browser/ top ten devices. [EDIT: To show the MB's speeds for various tasks.]

Data Xfer Rate Max =Max MB/s observed.

Each task that has been monitored was run on its own with only OS tasks running in the background.

(Overthere, thanks for your comments )

[overthere]

Here are the bottom lowest read transfer sizes, again arranged by transfer size. There are no physical disk reads. Looking at the rest of the log file physical disk reads only start to occur when read transfers are 4,096 bytes or above….hmm. Now I check writes.

Just to help clarify, the "transfer size" values discussed within the post above (as well as in the prior post 223) reflect the combined total amount of data transferred by all read I/O operations for the respective file (as observed by the hIOmon software).

The "summary" I/O operation performance metrics collected by hIOmon also include the minimum and the maximum data transfer size associated with a single I/O operation (each separately for reads and writes) - that is, the size of the smallest data transfer performed by a single read I/O operation (and similarly, the size of the largest data transfer performed by a single read I/O operation).

Ao1 also makes a keen observation about there being no physical device I/O operations associated with the various files shown within the post above (i.e., post #224, which shows the files with the lowest amount of data transferred).

This phenomenon can be the result of these files having been read into the system file cache prior to their being monitored by the hIOmon software in accordance with the currently-active hIOmon "Filter Selection" configuration file (that indicates which particular files, devices, and/or processes are to be monitored by hIOmon).

For example, one such scenario:

1. The hIOmon Filter Selection is activated; this Filter Selection says that the hIOmon I/O Monitor is to monitor and collect summary I/O operation performance metrics for file "x"
   
   
2. The hIOmon I/O Monitor subsequently observes the occurrence of a read file I/O operation directed towards file "x"; as a result, the corresponding data is transferred from the physical device into the system file cache as part of processing this file read I/O operation. The various "summary" metrics (including the "physical device metrics" reflecting the transfer of the data from the device) are accordingly updated by the hIOmon I/O Monitor
   
   
3. The hIOmon Filter Selection is subsequently re-activated (e.g., by running the hIOmon "SSD I/O Performance Analysis" script); as a result, all of the summary I/O operation performance metrics collected by the hIOmon I/O Monitor are re-initialized (i.e., reset to zeroes).
   
   
4. The hIOmon I/O Monitor subsequently observes the occurrence of a read I/O operation directed towards file "x". This read I/O operation does not explicitly request the use of the system file cache (consequently, it will not be recorded by the hIOmon software as a "SystemCache" type of I/O operation).
   
   However, the data transferred by this read I/O operation still resides within the system file cache (from step 2 above) and so the data transferred by the read I/O operation will be satisfied from that contained within the system file cache (and without directly incurring an associated read I/O operation involving the physical device; accordingly the "PhyDev" summary metrics remain unchanged).

[Ao1]

What you describe is how I undertook the monitoring, although I re-booted occasionally to clear the system cache.

I should have perhaps explained what I was trying to demonstrate in post #237. I wanted to show the maximum MB/s speeds that occurred on the device when undertaking typical tasks within a typical environment.

I captured the data Xfer statistics only to show that the maximum observed MB/s speeds were based on a reasonable amount of data being generated during the observation period.

The data Xfer totals are not necessarily derived solely from the task I indicated. Background OS tasks and cache movements would have had an impact. i.e. a read on the device could have been instigated before the monitoring period started.

Excluding file copying the MB's speeds are surprising low, although all of the tasks require processing time, so it should not be that surprising I guess.

With regards to system cache I've noticed that although I don't stress out the SSD, Cacheman 7 can improve the fast IOP count on both the system and the device. With a single device using Cacheman 7 I can achieve a higher fast IOP count than what I could with a Raid 0. (And it's a lot cheaper ).

TBH it is system cache that I find more interesting now in terms of looking for performance improvement with SSD. (Napalm (if you read this thread) it's taken me a long time but I'm getting there now )

I don't know how to test or prove it, but I would bet that something like Cacheman 7 that was designed specifically for SSD could really help to improve SSD performance. I say this as system cache has presumably been developed to mask the slow speed of a HDD rather than take advantage of the speed of a SSD.

[overthere]

I should have perhaps explained what I was trying to demonstrate in post #237. I wanted to show the maximum MB/s speeds that occurred on the device when undertaking typical tasks within a typical environment.

Thanks for the explanation - it confirms what I suspected was your intent.

Just to remind folks, the maximum MB/s rates that are included within your hIOmon metrics tables reflect the maximum amount of data that was actually transferred during a one-second interval as observed by the hIOmon software.

So for example, a 252.707 maximum read MB/s indicates that the hIOmon I/O Monitor observed 252.707 megabytes of data being actually transferred by read I/O operations during a particular one-second interval (with the hIOmon software also recording a timestamp for this specific, one-second interval).

[Ao1]

After monitoring for a couple of days I have saved a log file to pull off some stats.

First off I establish the top 10 read data xfer sizes. The chart on the left includes all data xfer events (cache and physical). The chart on the right only includes data xfer events that occurred on the physical device.

The top figures on the x axis are bytes. On the left chart there were 24,877 occurrences of 40 byte data xfers. 16,977 occurrences of 2,187 byte data xfers etc.

EDIT:

Some points of clarification. No Page file. Superfetch/prefetch disabled. Cacheman 7 running with auto optimised profile set to maximum performance.

[Ao1]

As above but for writes.

[Ao1]

Here I compare the amount of write data transferred at the logical device level (C:\) with the corresponding amount of write data transferred at the associated physical volume level (\Device\HarddiskVolume1:\).

[Ao1]

Percentage reads to writes

[Ao1]

Read Xfer Max Size

[Ao1]

Write Xfer Max Size

[Ao1]

Summary of read IOP's

[Ao1]

Summary of write IOP's

[Ao1]

Phy Dev Read IOPS

[Ao1]

Phy Dev Write IOPS