I noticed the Intel but didn't think it was a mistake?
Is this a SF raid or what?
If it's SF then it can take hours, it might need to idle overnight for anything to happen, if it's Intel then I expect nothing to happen.
Are you using the app I sent you a few days ago?
-
Hardware:
I only benched the X25-M once by mistake, which was right after I got the SF R0 array prepared to monitor GC. It’s a bit confusing as The R0 array is labelled as Intel Raid 0, but it is built with SF drives.
I’m using the first version of the Endurance app you sent me, just so I have a comparative workload, but when I’ve finished monitoring GC I will play with the newer version.
Okay, I'm a little confused at what is expected to happen with GC. Once you've written to all LBA's that data will stay there until overwritten as there is no TRIM at this time available using a RAID array. There might be a few pages shuffled around but I wouldn't expect to see any big changes.
some_one
As the drive is clean (all files deleted) one would expect GC to restore the speed, most of it if not all, if there is active GC, it might need to idle at some C state but it shouldn't be required in raid mode.
If there is data then nothing will happen, except if there are partial pages and cleaning (GC) combined several partial pages...
-
Hardware:
A little experiment on my boot drive.
2R0 m4 128GB with 61GB of data.
First there is an unknown state, a few days of use since last time I tested so just ordinary usage.
It does clearly show where files are stored.
edit: (more correctly it shows where data has been stored, the plateau from 96GB-236GB has never been used)
Then there is a 25.6GiB sequential write which leaves the array in the following state.
So, only by writing the file the array looks to be cleaner.
60 seconds of random writes
leads to this, one can clearly spot where the random writes have been written
So, I deleted the testfile (the 25.6GiB file) and wrote another ~25GiB to the array, the end result is like this. (no idle time)
The m4 does not reinstate full "speed" after such an exercise but it does clean up pretty good.
Last edited by Anvil; 11-09-2011 at 01:00 PM.
-
Hardware:
That's where you'd be wrong. Most SSDs have around 7% of flash available for controller use in excess of the advertised capacity. Even when the SSD LBAs are all used, GC still has about 7% of unused flash to collect together into larger chunks.Originally Posted by some_one
It is not clear to me. I see a transition at 47GiB, and another one at 96GiB.
Since you said it has 61GB of data (56.8 GiB), I would have expected the transition at around 56.8 GiB. Since it is R0, I would expect about half of that 56.8 GiB to be written to each SSD. But even so, I would not expect to see transitions at 47GiB and 96GiB, as your data shows.
I think it is clear that the 61GB of data is not all stored at the "beginning" (LBAs) of the SSDs. But it is not clear why there are two transitions in the read speed.
Am I missing something?
I found this on Wiki http://en.wikipedia.org/wiki/Garbage_collection_(SSD)#Garbage_collection
So far no real change.
“If the controller were to background garbage collect all of the spare blocks before it was absolutely necessary, new data written from the host could be written without having to move any data in advance, letting the performance operate at its peak speed. The trade-off is that some of those blocks of data are actually not needed by the host and will eventually be deleted, but the OS did not tell the controller this information. The result is that the soon-to-be-deleted data is rewritten to another location in the Flash memory increasing the write amplification. In some of the SSDs from OCZ the background garbage collection only clears up a small number of blocks then stops, thereby limiting the amount of excessive writes. Another solution is to have an efficient garbage collection system which can perform the necessary moves in parallel with the host writes. This solution is more effective in high write environments where the SSD is rarely idle. The SandForce SSD controllers and the systems from Violin Memory have this capability”.
Not really, there was another VM on the array which is deleted, it makes up the difference between ~96GB and ~61GB.
The part from 0-96GB consists of ~14days of activity.
Meaning that there has never been written data beyond 96GB.
edit:
I have added some info to the original post.
Last edited by Anvil; 11-09-2011 at 01:01 PM.
-
Hardware:
Thanks, that makes sense now.
I like this method you guys have been using of testing READ speed with HD Tune. At first I was skeptical of what you could learn that way, but it seems to reveal some interesting differences in how various SSDs work. I was biased against HD Tune for SSDs because of Anand's WRITE tests with HD Tune (which I think does not provide useful information, since large full-span sequential writes are so rare in actual usage). But using HD Tune for READ tests, combined with ASU to write data in various semi-realistic usage patterns, looks to provide some useful information. Well done!
I know it is a Frankenstein RAID, but are your 4k reads (with OP) faster than the 4k reads on the single V3?
Johnw, I am aware of drive provisioning. From Anvil's post (btw thanks for that Anvil) it seems to me that there is a performance penalty for access to non-contiguous media pages and/or pages that exist on different blocks. i.e. although the LBA's on the OS side are contiguous the mapping to the flash media is scattered all over the place.
Anvil's test of sequentially writing over the LBA's on the OS side will result in a new mapping of OS LBA to media pages and as the new mapping will be to the free contiguous pages of the blocks in the provisioning pool this results in better read performance. The old blocks then are GC'd to replenish the provisioning pool.
With Ao1's test of 4k random writing this will provide a new mapping for those pages that were written, with the old page mapping being de-allocated. This could leave some blocks with quite a few de-allocated pages which GC can clean up however, if by writing such that whole new blocks are mapped and filled with valid mapping then it will still leave the mapping substantially fragmented. This is why I'm not expecting a big change. GC would effectively have to defrag those pages to bring back read performance and I am not aware of that being one of GC's functions.
Using a RAID array it shouldn't matter if the file is deleted or not but maybe as a test the file could be cut and saved somewhere then copied back, the write could then possibly result in contiguous media allocation and result in improved read performance. Just a thought.*
I have very little experience with SSD's just having recently purchased them and that experience is limited to one model so if my thinking seems way off I hope you can understand and forgive me for any misconceptions I may have come to.
*EDIT: Might be better to physically read and write the file LBA region sequentially directly from/to the physical disk in case the windows copy changes the file cluster assignment.
Last edited by some_one; 11-09-2011 at 08:04 PM.
It seems like the RAID part of many of these tests is just adding needless complexity. What is really being tested is the behavior of SSDs without TRIM. But that can be tested by simply turning TRIM off in the OS.
First of all created 8GiB highly compressible 0-fill file.
Maybe a few clusters written outside the lines but IMO good enough.
Then 4k incompressible random writes to the 8GiB file followed by HDTune.
Reading the first 4GiB of sectors of the file and writing them back sequentially to the same sectors followed by HDTune.
Probably easier to just take the difference between reading contiguous sequential writes and reading random writes to get an idea of performance degradation through fragmentation. Since fragmentation can happen on both the OS side and the media side it makes things interesting.
Nice oneMy drive has not changed one iota. I’ll leave it for a while longer and then I’ll try writing 4MB 0 fill blocks to see what happens.
Perhaps true and the thread is now deviating, however as far as I know no one has looked at read performance degradation and how that relates to write patterns. As can be seen in post #47, trim restored read performance after a batch of 4K writes. In raid (no trim) filling the disk with large sequential xfers on a freshly SE’d array resulted in a 47% drop in read speeds.
Last edited by Ao1; 11-10-2011 at 01:32 AM.
OK, 12+ hours and not a stitch of movement.
4MB blocks.0 fill Delete files. Intriguing.
Write speeds are not fully restored however. Avg to fill array with 4MB blocks (non compressible) is 90MB/s
Interesting but otoh one would expect read spead to increase as the data is no longer compressed.
-
Hardware:
SF can be hard to read as there is so much variance between incompressible and highly compressible. Now that you have filled with 0's if you leave it for a while GC should be able to make use of all those media pages that have been freed. If you try filling it again later the write speed should be quicker.
I deleted the 4MB 0 fill files that ASU generated before I ran HD Tune. Do you know how HD Tune undertakes the read benchmark? I'm running a write benchmark now and it looks like HD Tune uses highly compressible data for writes.
HDTune for READ testing has always been useful, it's the only way I've found to visually detect changes while experimenting.
I agree, having said that one can't assume that the raid-driver operates like the none raid one and the granularity of files adds a new dimension to the reads.
I'm quite sure we would have seen other artifacts if the tests were done on a different platform as write combining/caching is handled differently.
It would be interesting to see if WBC On/Off makes any difference for the result. (except for write speed)
-
Hardware:
Even if you deleted the file, the data referenced by the LBA's were previously holding easily compressible data, it looks like the SF drives/metadata somehow reflects this.
You should check E9/F1 before and after a HDTune write test, I have never tried it for writes except for HDD testing.
I would expect HDTune to write either random data (essentially garbage from memory) or highly compressible data.
-
Hardware:
That was my conclusion. O fill would not have written to all of the nand yet the read speeds were restored across the array, so it would appear that the metadata records are slowing things down.
Last edited by Ao1; 11-10-2011 at 02:50 AM.
I checked results with OP, no OP in R0 and compared to a single drive. As expected in a fresh/ steady state 4K results (QD1) don't vary by much.
Yes, I agree, you guys are doing some interesting experiments. I was just pointing out that, IMO, the most interesting data relates to the behavior of SSDs without TRIM, which could be tested similarly to what you are doing here but on a single SSD (no RAID) with TRIM turned off in the OS. The RAID component of the test may also be interesting, but it is kind of running before learning to walk. It is usually better to start experiments with less complexity, and then once you understand everything in the simpler situation (single SSD without TRIM), then add on more complexity (RAID).
Posting Permissions
Reply With Quote
Bookmarks