Here I copy the Adobe folder from Program Files to the desktop:
2502 Items in the directory with a combined size of 710MB
http://img841.imageshack.us/img841/3373/fileadobe.png
Here I copy an AVI file from desktop to the C drive.
File size 635MB
http://img26.imageshack.us/img26/7766/17293796.png
You are on the right track. :up: The values as exported by the hIOmon software are:Quote:
Originally Posted by Ao1
Read Data Xfer = The accumulated total (in bytes) of the data transferred by the read I/O operations as observed by the hIOmon I/O Monitor.
Read Xfer Max Size = The largest data transfer size (in bytes) associated with an observed read I/O operation.
A couple of other further explanations of the metrics shown that might be of interest to folks following this thread:
1) The "FastIOPcounts" (e.g., the "ReadFastIOPcount"); these counts (for either read or write I/O operations) reflect the accumulated number of I/O operations respectively that were successfully completed in less than one millisecond as observed by the hIOmon I/O Monitor.
2) The "Read Time Total" and the "Write Time Total" reflect the accumulated total (in seconds) of the time durations associated with the respective I/O operations.
Consequently, you can derive the "average" response time by dividing the "time total" by the respective "IOP Count". So, for example, a "Read Time Total" of 11.9739501 seconds for an associated "Read IOP Count" of 37322 indicates an average Read I/O operation response time of .3208 milliseconds.
3) Similarly, the "Read IOP Max Time" and the "Write I/O Max Time" reflect the maximum time duration (in seconds) for a read or write I/O operation respectively as observed by the hIOmon I/O Monitor. So a "Read IOP Max Time" of 0.1502034 reflects a maximum read I/O operation response time of 150.2034 milliseconds.
Finally, there are many more I/O operation metric types that can be collected/exported by the hIOmon software.
For example, there is the "ReadDataXferRateMax" metric, which reflects the maximum data transfer rate, i.e. the maximum amount (in bytes) of data transferred by I/O operations of the respective type (i.e., either read or write) as detected by the hIOmon I/O Monitor during a one-second interval.
The various hIOmon clients can be used to add additional metrics to an export file. The hIOmon Add-On scripts can also be modified with a simple change so as to include additional metric types for export.
Thanks for the clarification. :)
So, outside of the monitoring results that included benchmarks the vast majority of read/ write IOPS are concluded in less than one millisecond. :cool:
When I copied a single 635MB file the max largest transfer size of 1.02MB is what occurred with a single read I/O operation? Now I'm struggling. The 635MB file is split into small "chunks" each with its own I/O operation? The larger the file the larger the "chunk" per I/O and the faster the write? Why are my Read/ Write Xfer Max Size typically comming in at around 1MB? Is that the optimum size for an I/O operation? (Sorry for being dumb again).
There is not necessarily a one-to-one correspondence between a given file I/O operation and any actual I/O operation to the disk drive itself.Quote:
Originally Posted by Ao1
As simple examples:
1) A single file I/O operation can incur two or more I/O operations to the disk drive (e.g., file fragmentation). BTW, the hIOmon software can capture I/O operation metrics that help empirically identify the performance impact of file fragmentation:
http://www.hyperIO.com/hIOmon/Screen...WMIbrowser.htm
2) Two or more file I/O operations can be satified by a single device I/O operation. This is largely the result of the "system file cache" usage.
For example, some data is read from the device into the system file cache (which is maintained by the operating system) and multiple file I/O operations are subsequently satisfied from the system file cache (rather than directly from the device).
See, for instance, the second screenshot on the following web page:
http://www.hyperIO.com/hIOmon/hIOmon...fQuestions.htm
Overall, the interactions between the I/O operation activity at the "file level" within the I/O stack within the operating system and the lower physical volume and physical device levels within the I/O stack can be complex.
This is a major reason why the hIOmon software provides the ability to capture/collect I/O operation performance metrics at all three levels (and, moreover, optionally do so concurrently so that you get a much clearer picture of what exactly is going on).
But back to your questions, there are a number of factors that can be involved in determining the particular types of I/O operations that will actually result from a "simple" copy operation (e.g., the nature of the copy program itself, buffering nuances, system resources available/used at the time of the copying, any other concurrently running processes, etc.).
So unfortunately there are no simple answers to your questions, but indeed the copying of a "large" file will likely entail multiple write I/O operations to the actual disk device.
Boy storage is complicated stuff. The more I think I've learnt the more I realise I don't know. :shakes:
HIOmon is really helping me though and I really appreciate your insights.
I've noticed that the ReadSystemCacheIOPcount and ReadSystemCacheIOPmissCount (same with writes) are always 0. I think the only exception was when I ran the winsat disk benchmark.
What does that tell me?
EDIT:
Also is there a way to monitor what happens when the PC boots?
I certainly agree: storage in general is inherently pretty complex. :)Quote:
Originally Posted by Ao1
The wide range of summary metrics made available by the hIOmon software provides an explicit reflection of this complexity in large measure.
Of course, the complexity involved in actually capturing/collecting/exporting/etc. these summary metrics is yet another matter! ;)
Anyway, regarding the ReadSystemCacheIOPcount and the ReadSystemCacheIOPmissCount metrics, these metrics reflect read I/O operations that, as observed by the hIOmon I/O Monitor, were directed towards a file and which explicitly requested the use of the system file cache. The same applies to the write variants of these metrics as regards write I/O operations.
As such, they only pertain to file-level I/O operations. Accordingly, these metrics are not applicable to I/O operations that are observed by the hIOmon I/O Monitor at either the physical volume or the physical device level within the operating system (and so, of course, their value will be zero in these cases).
The hIOmon software does provide an option to collect I/O trace and/or summary metrics during the system boot/start process.Quote:
Originally Posted by Ao1
This can get a bit tricky given, for instance, the volume of I/O operation activity that generally occurs during the system boot/start - along with the mechanics required to collect the requested metrics while the system itself is not fully operational yet.
If you would like to pursue this, please see the "Boot Logging" section (starting on page 68) and section "7.5 Boot Logging" within the "hIOmon User Guide" document.
Here I use the WMI browser to give me a live feed of the top 10 processes, whilst running all the typical programs that I use, namely: Power DVD, WMP, Photoshop, Modern Warfare 2 SP, Tracktor, Office, IE9, Messenger & MS Essentials (Quick scan).
Bandwidth
Interestingly MW2 SP only loaded at a max read transfer rate of 81.78MB/s
If I add up all the top ten maximum max read transfer rates I get a total of 327.12MB/s, so if I wanted to run all of the them at the same time I would need a bandwidth of 327.12MB/s, although that would not be physically possible to do. If I took out MW2 SP I would need a bandwidth of 245.35MB/s, which is possible with the X25-M, but again it would still be physically impossible to run them all at the same time. (Without running a batch file).
The fastest write speed I obtained was 42MB/s using Photoshop. If I add up all the top ten maximum max write transfer rates I get a total of 98.88MB/s, which is within the specs of an X25-M, but again impossible to implement together at the same time.
IOPS
The IOPS constantly change when being monitored so between selecting specific filters it keeps increasing, however it is clear to see that virtually 100% of IOPS are done in less than one millisecond. :cool:
Queue depths
The maximum QD's for writes surprised me but the averages (not shown below) are always below 2. The same with reads. I ran more proceses togther than what I would do normally to try and push the QD up.
Now I see exactly why a SSD raid 0 array was not any faster for my particular usage patterns in comparison to a single SSD. I didn't need the bandwidth or an increase in IOPS.
http://img109.imageshack.us/img109/8601/resultsf.png
those QD are for each individual process separately, correct? so you have some different processes, for instance the wmplayer, with 3. it has its own QD of 3, but that doesnt include the QD of other system programs at the same time. they each have their own QD. That QD is only its own, not the cumulative of the system as a whole.
you should configure it to read the QD of a entire drive, so that you get a cumulative number, and not numbers that are for each process separately. what is the entire QD for the drive? there are tons of processes/prgrams that are active in the background while you are running these individual programs. what about those? and how does that affect overall performance?
if you use the same setup as here with top ten monitoring you might get different results :)
as you see it is logging the entire C:\ drive, you would use the "top ten devices" instead of "top ten processes" to get this view.
http://i517.photobucket.com/albums/u.../QDTesting.png
also, when you are looking at the reads of each of these programs separately, it does little to tell you the read activity of the entire disk. there are other file accesses going on that are independent of each respective program...a program for instance is going to cause OS activity, etc.
you arent quantifying the 'collateral' access that is going on during your use, and that is just as important, or even more important, than the individual program.
you list the five processes that you put in bold on the Data Transfered_MB/s_Maximum Read graphic, but what of the other five above those? and what of the myriad of other things going on in the background that arent being tracked ?
testing only the singular, as opposed to the whole :)
Looks like an interesting tool :)
Haven't had the time to do any testing lately :(
yea currently on vacation myself :)
will be back to do some more testing in about 9 days :)
Hi CT :)
Enjoy your vacation :)
I'll be back in a week or two, a lot of things to try :) when I get back.
BTW, my first SSD (Vertex 250GB) bricked Friday a week ago, no data was lost though. (it died literally while I was doing the weekly backup)
I'm the 1st to admit....my storage use is not xtreme, but I wanted to monitor how I typically use the PC. If anything I had too many apps open to what I would normally run.
Max and AVG QD's are what I have more extensively monitored in previous posts, but here is the summary of the total QD'sQuote:
Originally Posted by Computurd
http://img696.imageshack.us/img696/76/qdmax.png
That is true. I'm only capturing the 10 ten processes, so there where many other processes running in the background. Totals can be seen in previous posts, which were obtained over a much longer period.Quote:
Originally Posted by Computurd
This set of monitoring was more to try and understand individual process demands. More monitoring is to follow ;) Next up the boot log. :)Quote:
Originally Posted by Computurd
Again this is only monitoring the top 10 processes, but I was surprised by how much the OS takes up. Some of those processes I don't recognise. I think MsMpEng.exe is MS Essentials. I ran a quick scan whilst I was monitoring. I have no idea what svchost.exe was doing, but I typically have quite a few of those running at any one time if I look in the task manager. There were also dozens of tiny traces from silly things related to my Asus D2X Audio Centre and Logitech apps. I did monitor all individual program files but the excel sheet was to detailed to post here.Quote:
Originally Posted by Computurd
Hi Anvil :wave:
@Anvil -ouch sorry to hear that :( lucky so far with my gen 1's, other than the three i lost when the 1500w psu blew up....still waiting for word from SilverStone as to whether they will replace the drives or not. they sent the psu and defective cable back to taiwan to confirm that was the root cause...
by no data lost, you mean you were able to get everything off of it? did it just cease to write?
(sorry for derail but i gotta know :) )
@A01-very nice work, does take time!
I would be curious to see the max read of all processes combined, even though i am sure the number will not be too fantastic, it is the nature of the accesses that will be important of course.
250 mb/s of sequential reads is a whole different animal than a 250 mb/s mixed read/write with varying levels of random and sequential, as the real accesses are.
of course it is an inherent weakness of all solutions, both HDD and SSD that they will not handle the mixed patterns very well. of course, that is the vast majority of real usage accesses!
that is another aspect that i find that arrays handle very easily, the mixed read/write accesses that are killer to single devices. of course, throwing on cache with a hardware raid card changes the ballgame entirely for the mixed read/write performance! makes life easy :)
You can see a summary of my highest totals in post #24
I don't know if I will do a boot trace next or if I should swap over to a HDD and run the same apps to see what happens. I somehow doubt that all the IOPS will be done in less than one millisecond. ;) Swapping to HDD is going to be a pain, but I'll do it on a system image so everything is the same apart from the SSD. Ehr.... loads of work, but I think the result will be interesting.
By the way its much easier to use hIOmon after you have installed Java. When will I learn to read the manual first. :rofl:
@CT
It just died within minuttes having performed the backup.
I'm not able to read or write to the drive (not recognized by any utility/mb), a pity as it was a great "all purpose" SSD.
edit
Hi Ao1 :)
I'll try to keep up with your findings, comparing SSD vs HDD using this tool would be interesting.
I've been using an HDD as a temporary replacement for the Vertex for a few days but it's not an option, at all :)
Comp, Here are the total reads/ writes for the top ten processes during that session:
http://img2.imageshack.us/img2/4117/read.png
http://img704.imageshack.us/img704/7239/write.png
Here is the outcome of monitoring a HDD. I used a system image so the HDD was configured exactly as the SSD and I used the same hardware system.
As I am monitoring general use I can't do an exact copy of how I ran various programs when I monitored the SSD, but I used the same programs as before. The multi task element included watching a DVD with Power DVD, whilst playing an mp3 with WMP and running a MS Essentials quick scan. I also open Tractor (Audio mixing) at the same time. I also did this for the SSD monitoring.
The hard drive was a Seagate Barracuda 160GB. I had a Rap, but it was too small for the system image.
Bandwidth
The a max read transfer rates were all lower than an SSD.
IOPS
I have now included max response times and here a big difference can be seen.
Queue depths
I expected much higher on the HDD, both peak and average. The max read QD was actually lower on HDD but the average QD for writes was much higher.
Having not used HDD for a while the obvious observations were slow boot and a lack of responsiveness when Windows first loaded. MW2 loaded noticeably slower, and during the multi task exercise the DVD playback became a bit choppy.
http://img835.imageshack.us/img835/636/hddr.png
Saved for bootlog
here is a comparison of the areca 1880IX-12 on the left, and the 9260-8i on the right, just kind of illustrating the difference in low QD speed from two uber cards.
The point is the killer speeds at the low QD, these are speeds that a single ssd cannot muster.
as you see, with throughput goes latency. the faster you serve the requests, even at low QD, the lower your latency is.
lower latency=faster performance. one thing that is agreed upon is that lower latency equals more speed :)
the low QD numbers for the array are miles ahead of single ssd, beginning at anything over 1 with the 9260, and just in total with the areca.
so...even at the lower QD, the arrays own. with the tremendous throughput of the array, it is easy to see why it is so hard to raise the QD. these are 4k random.
if there were mixed read/write patterns mixed in i would venture to say that the differences between the array and a single device would be even more of a mismatch.
EDIT: did a 4k test @ qd 1 with 75%read 25%write 100% random.
vertex LE single drive.................. 19 mb/s
areca w/5 vertex no read ahead:.. 47 mb/s (6gb test file)
http://i517.photobucket.com/albums/u...lie1/titlt.png
Would love to play this but the software completely messes up my OS after the initial install :(. BSOD at bootup. Had to safemode in and remove the service to get it to boot up again. I don't think it likes my nlited windows.
Here is a side by side comparision to compare more easily.
http://img177.imageshack.us/img177/8386/hddvsssd.png
From The SSDPerfAnalysisFS Filter
SSD
• Max Av QD Reads = 1.653
• Max Av QD Writes = 2.431
• Max Read QD = 18
• Max Write QD = 70
HDD
• Max Av QD Reads = 1.318
• Max Av QD Writes = 8.203
• Max Read QD = 13
• Max Write QD = 64
The other processes are either self explanatory or I don't know.
- iw4sp.exe = Modern Warfare 2 Single player
- MsMpEng.exe = MS Essentials (AV)
- Photoshop.exe = Photoshop CS 5 64 Bit
- Traktor.exe = Traktor Scratch Pro (Audio mixing)
- wmplayer.exe = Windows Media Player
- trustedInstaller.exe = I think I uninstalled Windows Gadget and then re-installed it.
- SetPoint.exe = Logitech wireless mouse and keyboard
Hi One_Hertz :wave: Yeah, most likely a nlited problem.
Here I directly compare the performance between HDD and SSD for Modern Warfare 2 SP. Fast IOP = less that one ms.
http://img834.imageshack.us/img834/7422/89003701.png
Here I directly compare the performance between HDD and SSD using Photoshop.
When I monitored this I only created and saved a 1.57MB file.
To compare what happened when working with a much larger file I created one @144MB. Max write speed increased to 82.10MB/s. (Using SSD)
Next I created a 316MB large format Photoshop.psb file. Max write speed remained the same. Here however my RAM and CPU were working much harder so the writes were probably a lot slower becuase I was waiting on the CPU/ RAM.
http://img207.imageshack.us/img207/4397/73438049.png
strange results tbh, dont know what to make of that, especially the QD ssd v hdd...maybe the writing was slowing down the reading with the SSD?
the fact that the max read and write are faster with the SSD makes perfect sense, and the fast IOP numbers all look in line with what i would suspect.
the QD though, is like the numbers are...dunno...unexplainable!
are the QD going higher on the ssd simply because it is reading faster, and can handle it better? i noticed the max reads are much faster for the processes with the ssd, and the fast iop count is faster, so common sense would say the QD would be lower...or is the system treating the SSD differently and requesting information faster....we know that the Win7 environment is optimized for SSD and that it handles them differently. but that much difference? wondering if the results would be the same with vista? headscratcher for sure. what about NCQ and ACHI, are they accessing information in a different manner from the SSD? when you think about it, faster read/write SHOULD equal lower QD!!
doesnt make any sense either, how can the drives have different amounts written/read from them in the total sections..the write iop count comparison is wrong, you have 40K writes compared to 11k writes, so that isnt the same...would throw the numbers off. the max data writes are way different too...even though you wrote the same amount of info for example:
photoshop test:
max data transferred HDD; 283,496,448
max data transferred SSD; 778,919,936
but you ran the same test on them? why would it write 2.7 times more data to the SSD for the same size file?
for the modern warfare 2 the results are much the same...tremendously more amount written to the SSD with the exact same usage?
seems like all of the write comparisons across the board follow this same pattern here. your read numbers for amount transferred look very close though. are you sure that you cleared the test before you ran them again on ssd?