About time we started to see the iodrive in action. It would be nice to see some more.![]()
What would you like to see?
The most interesting part (to me) I already saw... Looking at average response times, iodrive took 0.045ms*60k = 2.7 seconds to serve the required data (reads), while X25-E array took 4.4 seconds. The savings of 1.7s in load times between the two game loads are very close to what actually happens when I compare with a stopwatch.
So theoretically, if my storage system was infinitely fast, I would shave another 2.7s off my load times. The rest is bottlenecked by other components (CPU mostly).
I would be interested to confirm exactly where the iodrive gains so much over the x25-e array... It is obviously the low QD small file performance, but it would be nice to confirm.
I've got a handful of iometer tests I'd like to see/collect for my graphs![]()
-
Hardware:
If would be great to see some Real Time I/O Summary shots at the device level that captures game play and compares a single X25-E, R0x4X25-E and the iodrive.That should give a clue as to where the iodrive is performing better. It would be interesting to see where that was
![]()
I need to buy another SSD so my OS does not need to sit on my X25-Es. It has been the plan for a while to buy the new sandforce controller and throw windows on there, which would allow me to run X25-Es on my LSI9211 in dynamic raid. I am just waiting for other companies to get access to the new gen sandforce as I don't want to buy an OCZ drive due to their business practices.
A new version of hIOmon will soon be available and it has a great new feature that captures Performance Threshold Range Metrics.![]()
Below is a screen shot that captured threshold range metrics during a Win 7 boot.
To explain the stats.
For reads a total of 27,918 I/O operations were observed over a 360 second duration. Over the 360 second observation period:
• 61 seconds accounted for IOPS activity below 100.
• 2 seconds accounted for IOPS activity between 2,000 & 4,999
During the 360 second observation period a total of 577.01MiB of reads were recorded. Over the 360 second observation period that those reads were incurred:
• 55 seconds accounted for read speeds less than 1MB/s
• 1 second accounted for read speeds between 100 and 200MB/s
Out of 27,918 I/O operations a total of 10,833 were above QD1.
Out of the 10,833 I/O operations 6,242 were at QD2. 34 operations were between QD 8 & 15.
Later I will post a summary of performance threshold range metrics that occur over a day's worth of typical use.
![]()
Last edited by Ao1; 07-16-2011 at 11:28 AM. Reason: changed QD to I/O in bar graph
This is looking really great!
Looking forward to do some sessions, I might do another VMWare based comparison.
-
Hardware:
now that is some interesting stuff there, i really like that capture. so this is all bootup? i wonder what that would look like with loading some intensive (somewhat) app like transcoding. That sounds good, hint hint
i would be extremely interested to see transcoding capture during like a conversion of a file to MP4.![]()
"Lurking" Since 1977
![]()
Jesus Saves, God Backs-Up *I come to the news section to ban people, not read complaints.*-[XC]GomelerDon't believe Squish, his hardware does control him!
Sorry, I did not read the whole thread. But did anyone measure the impact of Readyboot (Preloading + Prefetch + Cache) yet? On my system Windows 7 does *not* deactivate Readyboot, Prefetching and Superfetch even with a WEI of 7.9 on the SSD.
My own less sophisticated measurements came to the result that it doesn't really matter whether Readyboot is enabled or not. The only difference is that with Readyboot all data (aka services, sys, dll, exe) is loaded in one bulk at the very beginning of the boot process and cached for later access (plus some write access caching). Without RB everything is loaded the moment it is needed (i.e. when a service is started), but the overall boot-time (sum) pre-login and post-login seems to be the same.
The latter seems to imply that SSDs like my M4 already get pretty close to maximum boot performance even in comparison to RAM cache. Or better to say, that during boot the number of "first" time loads is a lot higher than the number of "repeated" loads (of data that has already been accessed before).
thanks for running the M4 testing Ao1. I knew it was CPu intensive, but man it really doesnt use the HDD at all. There is a app that does it with a Nvidia GPU, called badaboom. It is supposed to be the fastest (of course it uses CUDA and the amount of cores on your gpu) i wonder what disk uasge would be using that.
@Timur-interesting. Could it be that readyboot is disabled automatically when an SSD is detected? We know that MS disables some features when it is detected, but i think it is fuzzy as to all of the things it disables. I guess one would have top watch the boot process with a HDD then compare to a SSD?
"Lurking" Since 1977
![]()
Jesus Saves, God Backs-Up *I come to the news section to ban people, not read complaints.*-[XC]GomelerDon't believe Squish, his hardware does control him!
Nope, that what I meant. Readyboot, prefetching and Superfetch are explicitly not disabled here (only defragging). I disabled Readyboot manually and measured the boot process both with Xperf and Bootracer.
Xperf nicely shows how the files are loaded at different times when RB is used (all files loaded at the beginning into a RAM cache) or not used (all files loaded when needed). RB has the advantage of offering a RAM cache right from the very start of the boot process and with good trace files you get over 90% hit rate. But it does have some overhead of files that it loads even when they are not needed (that last 10%, can be higher when you change something without the traces being updated yet).
Thanks to all above for the positive response to the upcoming new hIOmon "Performance Threshold Range Metrics".
And special thanks to Ao1 who passed along some great suggestions for further refining the "Bar Chart" graphs!
A minor point of clarification regarding the Bar Chart screen shot for Read I/O operations as shown in post #359:
The annotation shown for the "IOPS 100 - 499" value is meant to indicate that there were 16 separate one-second intervals (over the course of the 360 second Observation period - and these 16 seconds are not necessarily contiguous) during each of which the hIOmon I/O Monitor actually observed between 100 and 499 read I/O operations.
wow that looks to be much more intensive on the storage system, with much more loading @ the somehat higher QD. interesting. So the speed of the conversion definitely matters (of course)
@timur-interesting...it would be cool if there were a way to manually adjust the cached variables, even though that wouldnt be a good time taken v performance gained ratio.
"Lurking" Since 1977
![]()
Jesus Saves, God Backs-Up *I come to the news section to ban people, not read complaints.*-[XC]GomelerDon't believe Squish, his hardware does control him!
wow that looks to be much more intensive on the storage system, with much more loading @ the somehat higher QD. interesting. So the speed of the conversion definitely matters (of course)
@timur-interesting...it would be cool if there were a way to manually adjust the cached variables, even though that wouldnt be a good time taken v performance gained ratio.
"Lurking" Since 1977
![]()
Jesus Saves, God Backs-Up *I come to the news section to ban people, not read complaints.*-[XC]GomelerDon't believe Squish, his hardware does control him!
You would have to hack the trace logs for that (ending fx inside the Windows\Prefetch\Readyboot folder).
Here is an example of what RB does. "Hits" means cache hits during boot, so these are files which would have been loaded several times without the RB cache. "Misses" means files that have not been prefetched and cached by RB. Every time you do a reboot a new trace file is created (5 in total, the oldest is deleted) to handle the prefetching for future boots.
![]()
Last edited by Timur; 07-16-2011 at 01:43 PM.
amazing that! very good ratio of hits to misses for surelooks to be pretty efficient.
"Lurking" Since 1977
![]()
Jesus Saves, God Backs-Up *I come to the news section to ban people, not read complaints.*-[XC]GomelerDon't believe Squish, his hardware does control him!
And only one reboot later the picture has already changed. Not only concerning Readyboot, but also concerning when things are read and written. All those cache misses of the last screenshot at around 40s where "long" after my system logged in, so likely I manually started something that RB did not know about. Superfetch did not do its prefetching at this time yet neither (I think it wait 2 minutes in W7?), but that wouldn't show on that graph anyway. And with SSD this doesn't all really matter much in practice, still I will take a look with hIOmon to see what happens with and without RB.
Because of the somewhat changing nature of the boot-process measurements of boot-times and access pattern has to be repeated several times without any changes done to the system. Frankly I always wondered how review sites can post "exact" numbers for boot-times, sometimes even with a decimal point? Mine keep changing with every reboot and I assume that they do so on most other systems with a minimum of software installed.
When does hIOmon exactly start to measure? What do we learn by running hIOmon during boot?
![]()
Last edited by Timur; 07-17-2011 at 12:41 AM.
^ Boot up can be considered in three stages. Please see the first post for an explanation of these stages and details of what hIOmon can monitor. (Post #32 also provides clarification).
Thanks for pointing to post #32. I will run hIOmon through xbootmgr/xperf to see when it is started exactly.
Bookmarks