Ao1 kindly provided me with the "hIOmon Manager Export File" that contains the summary I/O operation performance metrics which were collected by the hIOmon software and which were the basis for his post #268 above.

Based upon my initial analysis of this export file, the metrics contained within the file appear valid.

The analysis is rather involved, but I will try to highlight at least some of the major points here. But first some important background information.

Firstly, the export file contains a default set of 66 summary metrics, which represent a modest subset of the over 200 or so summary metrics collected by hIOmon that are available for export. As a result, there are several additional metrics that if present within the export file might provide additional substantiation.

Also please note that no "I/O Operation Trace" metrics were collected; hence, there is other supplemental information that could also provide additional substantiation.

Secondly I would note that a "top-down", iterative approach is one which I generally recommend when using the hIOmon software to explore particular issues of interest (especially in contrast to starting out by collecting mountains of I/O trace data and then having to plow through it all so as to find, for instance, some anomaly - and assuming that you know what you are looking for from the start).

So the basic idea is to begin with a small but prudent set of summary metrics, and then subsequently include additional summary metrics as indicated/suggested by the analysis, and only resort to I/O operation trace data if actually needed - all dependent, of course, upon the particular topic that you are trying to tackle.

Anyway, here are some major items of note revealed by the export file:

  1. The "aberrant 512B" was a single physical volume read I/O operation that took 499.2341 milliseconds to complete!

  2. The "C:\Windows\SysWOW64\HsSrv.dll" file encountered this villainous data transfer during the 10 minute period prior to 18:14 on 28 February.

  3. During that 10 minute time period, there were two file I/O operations to the "HsSrv.dll" file, both of which occurred concurrently (since the "Read Max Queue Len" metric value was "2").

  4. Each of these file I/O operations transferred 26 bytes of data (since the "Read Xfer Max Size" value is "26" and the "Read Data Xfer" value - which reflects the total amount of data transferred - is "52").

  5. The value of the "Read Random Access IOP Count" metric is "1", which indicates that the data transferred by these two file I/O operations was not contiguous.

  6. The value of the "Read Time Total" metric is "998.5618 milliseconds"; this value reflects the combined total time required to perform both of these FILE level I/O operations. Please note that this is I/O operation response time observed at the file-level within the OS I/O stack and not that seen further down at the "physical volume" level within the OS I/O stack.

  7. The value of the "Read IOP Max Time" is "499.3092 millseconds"; this value reflects the maximum I/O operation completion time observed for the associated file I/O operations. Consequently, one of the file I/O operations completed in 499.3092 millseconds (i.e., the max) and the other in 499.2526 millseconds (which combined equals the 998.5618 milliseconds read total time).

    This also coincides with both I/O operations having been queued together (see 3 above).

  8. As noted in (1) above, the physical volume read I/O operation (to transfer the 512B) required to satisfy these two file I/O operations took 499.2341 milliseconds, which coincides with the I/O operation completion times for the associated file I/O operations.

  9. Now for the bigger picture, the hIOmon software began monitoring I/O operations at approximately 18:03 on 28 February. Actually, the export file shows that the hIOmon software had previously been monitoring I/O operations the preceding day, with its last prior entry into the export file occurring at about 22:40 on 27 February.

    Generally the hIOmon software is by default started automatically when the various services are started as part of the system boot process. There is typically quite a bit of I/O operation activity occurring as the various services get up and running.

    Indeed, the "device summary" metrics within the export file shows during the approximately 10 minute period (ending about 18:13) shows that there were 31,337 physical volume read I/O operations that transferred a total of 691,739,648 bytes of data, with a maximum data transfer size of 29,618,176 bytes, a "Read Max Queue Len" of "41", a total combined time of 24.9406942 seconds, and a "Read IOP Max Time" of 500.0811 milliseconds (so some other physical volume read I/O operation was even more unfortunate than the aberrant 512B ).

    On the write side during this same 10 minute period, there were 7,273 physical volume write I/O operations that transferred a total of 226,802,176 bytes of data, with a maximum data transfer size of 2,105,344 bytes, a "Write Max Queue Len" of "34", a total combined time of 3.3205158 seconds, and a "Write IOP Max Time" of 19.8715 milliseconds.

Overall then, it appears that the "aberrant 512B" got caught up in the physical volume I/O operation activity that ensued as part of the services startup activities performed when the system was started.

As mentioned above, further substantiation would require that additional summary metrics be included within the export file.