I've recorded an HDD Suite using the PM, I'll have a look at you guide later and do a re-run
Max QD was 77 which is quite high. (read)
Busy time was merely 16-17 seconds
I've recorded an HDD Suite using the PM, I'll have a look at you guide later and do a re-run
Max QD was 77 which is quite high. (read)
Busy time was merely 16-17 seconds
-
Hardware:
Hi Ao1,Originally Posted by Ao1
Perhaps PCVM is using some other temporary directory as part of its actual benchmarking I/O operation activity.
Here's my HDD suite test. (for reference)
The test is performed on drive I. (not the OS drive)
HDD_SUITE_3R0_INTEL_NON_OS.PNG
-
Hardware:
Here is the log file from the HDD suite test.
(I don't have Excel installed on this computer and so I haven't looked at it yet)
Ao1,
As overthere noted, there are other directories that needs monitoring, not sure of where they are located, they are created on the fly during the benchmark.
Monitoring C:\* for a single run should do the trick. (for finding where it processes the data)
Last edited by Anvil; 11-14-2010 at 09:36 AM.
-
Hardware:
Dang, your right. It creates a temp file that does not get monitored from the folder. I've consequently deleted post 173 & 178.
OK, this looks more like it. I ran the storage benchmark only and only changed the target drive setting. The drive tested was my storage drive with very little free space. The score dropped to 27,722 compared to 30,963 on the C drive. Now we can start to see a real difference between a single ssd and a raid array
Last edited by Ao1; 11-14-2010 at 10:45 AM.
This is my latest run, let's see if the numbers compare
HDD Suite, target drive : I: (3R0 Intel G2 SS16KB)
Score : 83356
-
Hardware:
Anvil, the data transferred is not an exact match, especially on the writes, but it’s clear enough to see a story.
Yes, there's a huge difference on writes, quite a bit on reads as well but not that spectacular.
If you look at the seq/random write distribution on my run vs yours there is something odd going on, most of my writes are sequential.
QD was quite the surprise, there is nothing normal about QD ~80
Was this my latest run?
-
Hardware:
I had an issue monitoring software raids a few post back.
overthere informed me about using drive letter + ? (i.e I? for drive I) for software raids and it worked
Problem solved!
Notice that I've highlighted Control I/O (TRIM related)
vm_boot_build_shutdown_ICH_SWRAID_3R0_G2_160GB_2.PNG
TRIM does work on Software RAIDS in W7
y.PNG
Last edited by Anvil; 11-14-2010 at 03:31 PM.
-
Hardware:
Hi Anvil,I had an issue monitoring software raids a few post back.
overthere informed me about using drive letter + ? (i.e I? for drive I) for software raids and it worked
Problem solved!
Notice that I've highlighted Control I/O (TRIM related)
TRIM does work on Software RAIDS in W7
Good to hear that the "workaround" helped.
In the case of the hIOmon "SSD Performance Analysis" script, basically what this "workaround" does is to configure the hIOmon software so that the "physical volume" (rather than the "physical device") associated with the specified Logical Drive/Disk (i.e., logical disk "I" in your case) is monitored by the hIOmon software.
This is why you see "\Device\HarddiskVolume5" shown within the hIOmon Presentation Client display (rather than, say, "\Device\Harddisk1\DR1", which reflects "physical device/disk number 1").
There is another nuance, specifically with TRIM, that I would also like to mention here.
Basically, the software driver at the physical volume level within the I/O stack can honor a TRIM command for a physical volume whose associated physical device does not successfully process the TRIM command.
That is, the hIOmon software can observe the completion status of the TRIM I/O operations performed at the physical volume level as having been successfully performed by the software driver (and even though these TRIM commands were not actually passed downed to the physical device).
You can verify this TRIM nuance with a HDD running under Win 7. The hIOmon software can observe the "successful" completion of the TRIM commands at the physical volume level, but with the (single) attempt of a TRIM command at the physical device level observed by the hIOmon software as being unsuccessful - so consequently no additional TRIM commands will be passed down to the physical device.
BTW, this is also why the hIOmon "SSD Performance Analysis" script - by default - always configures the hIOmon software to monitor the specified "physical device" (rather than the "physical volume").
A few people have said they can't open the quick set up guide I posted in post #175, so I have re-attached in Word docx format in a new zip file. Due to attachment limit I can't zip in a pdf format, but if you still can't open it feel free to PM me and I will email it to you.
Interesting. I thought that Win 7 only sent a TRIM command if the storage device reported a non spinnning status
Hi Ao1,Interesting. I thought that Win 7 only sent a TRIM command if the storage device reported a non spinnning status
I recall seeing something somewhere along the lines of your comment above.
But using the SSDPerfAnalysis script along with the "x?" option (to request that the physical volume associated with the Logical Disk "x" be monitored rather than the associated physical device), I have re-confirmed (using a VMware virtual machine running Win7-x64 with virtual HDDs) that TRIM commands are seen by the hIOmon software as being successfully processed at the physical volume level within the operating system I/O stack.
I will continue to revisit this some more ...
Here I monitor boot up with a little more precision. (For me anyway) Total boot up read transfers = 53MB. One and a half hours later doing nothing but work with Excel I had 1,573MB of read transfers and 101MB of writes.
This chart shows the read transfer sizes. Less than 200 bytes = 920. More than 200, but less than 400 = 233 etc.
In total 2,772 read transfers were recorded. Only 16 were above 1MB:
Last edited by Ao1; 11-22-2010 at 02:00 PM.
I knew that writes would be low but 101MB is almost nothing, maybe W7 is super efficient after all.
Doing fw updates on my C300s, if all goes well I might post some info tonight about monitoring software raid, each drive individuallyand the "drive" as a whole.
(got a special delivery from overthere for monitoring the drives individually while in raid)
-
Hardware:
To help dispel the notion/concern that the observation by hIOmon (see my post #189 above) that "Win 7 successfully issues TRIM commands to HDD-backed physical volumes" was somehow due to running within a virtual machine environment, yesterday evening I ran the hIOmon software upon a "native" Windows 7-x64 system (i.e., a laptop with a single HDD and only Win 7-64x installed) just to make sure nothing has changed (i.e., from prior testing by hyperI/O).
The results were the same: multiple "successful" TRIM commands observed at the physical volume level within the operating system I/O stack (but none at the physical device level).
This re-confirmed once again (as was first noticed well over a year ago
The ability to discretely monitor I/O operations at the physical volume level (in addition to the physical device level) helps bring this nuance of TRIM within Win7 to light.
That should be interesting. others have posted that writes are far from evenly distributed on 2 drives on a raid 0 array.(got a special delivery from overthere for monitoring the drives individually while in raid
I’ve been wondering why Windows had a big variation in the boot up data that got loaded from my previous posts so I ran a check on the HDD image I kept that was made from an old OS.
It seems that the boot up processes consists of core files only. Once the boot process is complete significantly more files get read and they are mostly very small random reads. Within around 15 minutes of the desktop first appearing a further ~1.5GB of data is read, which consists of program, user and Windows files. This is without doing anything and it happened on a relatively new OS and an old OS.
Previously when I monitored boot up I did it on a time basis after I thought Windows had finished loading, but clearly things keep getting loaded well after the Windows desktop is launched.
This explains why I was getting 400MB reads, as I was capturing data a couple of minutes after Windows had first loaded.
On a seperate issue the Intel mod recently posted this on their forum:
“Intel SSDs do not have idle time garbage collection (ITGC) or background garbage collection (BGC) Some SSD controllers like Indilinx Barefoot, SandForce SF-1200, or Samsung S3C29RBB01-YK40 do have this feature. This is an internal feature of the drive. The controller determines when it is idle for long enough and then does a file system compare against what is actually valid on the drive. It then cleans up the dirty pages. The actually implementation of garbage varies between controllers though. The downside to idle/background garbage collection is write amplification as it may perform unnecessary writes.
While Intel SSDs do not idle/background garbage collection, they have are very resilient to dirty pages. I believe this is what you are referring to when you say realtime garbage collection. Then impact of deletes varies between controllers and has to do with how the drive decides manages data.”
Excellent observationThis re-confirmed once again (as was first noticed well over a year ago
The ability to discretely monitor I/O operations at the physical volume level (in addition to the physical device level) helps bring this nuance of TRIM within Win7 to light.
When I had my mp3’s on an external USB HDD WMP would, on occasion, become unresponsive. This seemed to happen when the media information was synchronising.
To look into this I decided to compare what happened when I played mp3’s with WMP from a standalone SSD I now use for storage and an external USB HDD.
I played the same 8 mp3’s from the SSD (E drive) and on USB HDD (F drive) The combined mp3 size on disk was 77.5MB with 49 minutes of music playtime.
In total I have 59.6GB of MP3’s. They are all in one folder with 1,009 sub-directories. Content indexing on the E & F drive is enabled when just playing mp3's.
During the monitoring period I did not access the E or F drive other than load the MP3’s.
Entries were generated by the following processes:
• MsMpEng.exe = (MS Essentials)
• System
• Wmplayer.exe (Windows Media Player)
• Explorer.exe
• Dllhost.exe
Before running the mp3 folder synchronisation on the USB drive I disabled file indexing, but I did not disable file indexing on the SSD when I ran the same task. Maybe that is why the reads were so much lower when synchronising the mp3 folder with the SSD drive.
Either way it’s easy to see why I prefer using SSD for storage over a USB HDD.
Last edited by Ao1; 11-27-2010 at 11:55 AM.
I haven't forgotten about this thread
(I'm on a short vacation)
Ao1,
Interesing and expected results for the USB drive, get yourself an eSATA docking station
-
Hardware:
I went one better and got an SSD
I’ve been doing more work trying to find out what happens pre boot and after boot. I’m close to working it all out so soon I will be able to post some results.
Can't argue with your decision
WD SiliconDrive N1x (SLC) were on sale a few weeks ago on one of the main computer shops in Norway, more than 50% off and so I had to order a few of them.
(they perform almost exactly like the SiliconEdge Blue and so they are quite nice for active storage)
-
Hardware:
Hi Anvil,
I’ve had a bit of time to look into the boot process and I can share some of my observations.
If you only monitor the boot processes related to Windows the data transferred is quite small, although it is almost exclusively small random reads. What I have established however is that Windows keeps on loading well after the desktop 1st appears. I’ve also established that non Windows apps get loaded before the desktop appears, so Windows files are getting loaded in parallel with non-Window based applications.
What you have installed on the OS can therefore make a big difference in the period before the desktop appears. The amount of data that gets loaded after the desktop appears is highly variable. I’ve seen between 400MB and 1.7GB of read transfers within 15 minutes of the desktop first appearing without doing anything.
The data that gets loaded after the desktop is also predominately small random reads, although larger data transfers typically appear. The processes that generate read transfers after the desktop appears are highly variable.
I’ve kept a couple of Excel files that show pre and post desktop process that generate read transfers. They are too large to post here, but if you are interested I can email them to you.
Here I run a manual TRIM with Intel’s Toolbox. I had run it a few times before recording the outcome below.
This is in AHCI mode. Intriguing that some of the temp files are called TRIM Raid. I got the same with the Toolbox version 1.3 and 2.01 and with MSACHI drivers and the latest RST drivers.
Posting Permissions
Reply With Quote
Bookmarks