Yep it would have been in a steady state on the AS SSD run. I didn't open up the case to see what NAND was being used in case I got any BSOD weirdness and had to return it. So far so good though. Once I get it to a throttled state I will open up the case.
I'm still getting the TRIM hang btw. Doesn't seem any different to the V2.
AVG speed now 64.81MB/s (0.22TB)
Is it as noticeable as it was on the V2, meaning 10 seconds or so?
-
Hardware:
It would still be interesting to test it on SATA 3. I'm curious to see if writing zeroes would max out the interface. Also, could you do same tests trim vs non trim and look for WA?
Originally Posted by Anvil
Last edited by Ao1; 07-19-2011 at 03:23 AM.
Like I wrote before, the ATTO testfile itself becomes a lot less compressible when you use that random I/O comparison (only down to around 90% via 7Z fastest w/o solid). So the reduced write performance is likely due to SF's compression working hard on that file.
This would also fit in comparison to AS SSD, which is even less compressible than the ATTO random file and thus shows less sequential write performance.
What I wonder about is: Is the resulting write performance due to slow NAND writes of the SF drive, or due to the SF trying to compress the data even when it's not really compressible?
Anvil suggested that SF may only compress data that's at least 66% compressible, but I doubt that SF is able to detect that before trying. Because in order to do that it would have to analyze the data on a "content" basis (i.e. don't try JPG, MP3, ZIP, etc.), which I don't think it can do (at least not with a proper RAM buffer for pre-analysis). 7Z/LZMA2 tries to avoid recompressing already compressed files and still it has to go through the whole file at full compression time first (even knowing its ZIP extension).
Last edited by Timur; 07-19-2011 at 03:59 AM.
I assume you have LPM Slumber disabled in order to identify TRIM hang from LPM hang?
The "hang" is a known issue on the SF controller (deleting large files or a lot of files will result in a "hang" during TRIM), it's got nothing to do with LPM.
I was hoping that this one was gone but apparently not.
(personally I always apply the "LPM fix" on SnB systems)
-
Hardware:
One of the benefits of the MSAHCI driver over the Intel one is that you can switch LPM states (+Slumber activation time) via power-profiles without need to reboot. It even allows to use different settings for battery operation. OS X uses a Slumber timer of 40 ms by the way, Windows "Balanced" and "Power Saver" profiles are set to 100 ms, "High Performance" turns LPM off (only with MS driver).
The ~67% is based on the compression ratio of a file (or a collection of files) found by using 7Zip "Fastest" and when written the E9 and F1 SMART attributes increase at the same rate, which indicates that "no" compression is performed. (WA is ~1.0)
The SF1 series controller told us in 64GB steps how the data was written, now with the SF2 series it is considerably easier to measure as the counters are showing raw/host writes in 1GB steps.
In real life it won't get a constant stream of some "known" type of data, it will most likely be a mix where in general the smallest package is ~4K and the largest package is ~128KB.
(there will be extremes like 512B and multi MB packets but those arent typical)
The SF controller sees only packages of data in streams, it has no concept of files and so looking for extensions is out of the question.
-
Hardware:
Of course looking for extensions is out of question. That is why I wrote that SF would have to be "content" aware (analyze and guess content) and that even 7Z's LZMA2 needs to go through *all* of the content even while it could be extension aware, which obviously it is not. Software compressors usually are content aware in that they use different algorithms for different source files (both RAR, 7Z and current WinZIP do that unless you force them not to).
So when 7Z with the power of an i7 and 7 gb RAM at its disposal has to compress through the whole incompressible file just to reach 100% (aka no compression, aka just store) then I doubt that SF with its lack of memory can do any much better (still no idea about its "dedicated" computing power).
My somewhat educated guess (!) is that SF does nothing of that sort, but just tries to compress everything coming in with some algorithm that similar to LZMA2 avoids ever going over 100%. In that light the 67% limit you identified would be the turning point from which on SF's compression engine fails to get any more compression out of 7Z file.
And since the difference between compressing to 100% to storing at 100% is throughput I wonder if SF could be faster with incompressible if it wouldn't try to compress it in the first place?! Why else would incompressible only write at around 70 mb/s? Or do you think SF is sooo much slower to push uncompressed data to its NANDs than other SSD processors (i.e. Marvell)? Maybe it is, but with all the computing put into compression there should be enough juice for just storing away.
Last edited by Timur; 07-19-2011 at 06:46 AM.
The SF2 series controller is capable of writing incompressible data at about 280-290MiB/s, that is, with the optimal NAND/die "setup".
OCZ lists the specifications for the incompressible data rate, it's not a secret at all and ~70MiB/s is in line with the specs for the 60GB V3.
(depending on the block-size)
v3_spec.PNG
-
Hardware:
In my argument I forgot that those Vertex 3 240 gb come at over 240 mb/s when fresh. So my last argument isn't so valid as it seems.
Edit: You posted just before I hit the Post button.
+1 poor trim implementation. for those that missed it seems a fix is inboundThe "hang" is a known issue on the SF controller (deleting large files or a lot of files will result in a "hang" during TRIM), it's got nothing to do with LPM.
SATA 3.1
"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!
Just noticed, the V3 has a number of new SMART attributes. 230 (E6) should be interesting.
@Ao1
Could you do some more zero fill tests? I would be interested to see how much data you need to write to see 80 increments in #233 smart parameter. The data from post #245 is interesting and odd in the same time compared to V2
Sure, but let me get the drive to a throttled state first.
Don't forget for the V3 I only wrote to clean NAND, so WA was excluded.
I don't know why the installations compressed by 50%, but the data folders stayed the same. The documents folder should have been quite compressible. (Office docs, pdf docs and three web sites).
Are you going to test the WA of the other settings from Anvil's app before you hit LTT?
If by Office your meaning MS Office 2010 then they are internally compressed.
So, I don't find your results unlikely at all.
-
Hardware:
Probably because some of the files in the Windows installation had very easily compressible data, like bytes repeated over and over, while the document folders did not have anything so simple. I've always thought that Sandforce's compression algorithm is basic, and cannot compress anything more sophisticated than a short repeating pattern like zero-fill or repeated bytes.
Last edited by johnw; 07-19-2011 at 12:56 PM.
Not sure what you mean?
Currently Anvil's app is running with non compressible data and whatever the default settings are for random writes.
Once I have followed John's method I can do loads more on compression. The extra capacity of the V3 plus 1GB reporting will make it a lot easier to experiment with.
Last edited by Ao1; 07-19-2011 at 12:58 PM.
If I am reading his posts correctly, Ao1 is talking about his documents folder which totals 5444933198 Bytes. Ao1 showed a RAR .zip archive of documents that was 3155165184 Bytes. That comes to a compression ratio of 57.9%. Seems reasonable for a documents folder. But Sandforce's compression algorithm cannot compress the documents much at all. Which agrees with what I have often said, that Sandforce's compression algorithm is quite basic and can only compress simple repeating byte patterns well.
Office docs like Word/ Excel & Power Point. (Created in Office 2007)
Those folders contained real data and included all the common files I use. The only other "real" data I could throw at it would be more installations.
There's 5 (or is it 6?) settings for data compressibility with Anvil's app, I only see you've published ~WA with 0-fill setting
You should still have many TiB of wiggle room before LTT kicks in, why not try seeing the compressibility of more things? Try out Anvil's various settings, take your current Program Files directories and copy it onto the V3 and other stuff
It's really starting to look that way. I can't say the compression factor made the Windows or Office installations any quicker either.
Reply With Quote
Bookmarks