Althought the article here was very informative, it make me think about a question of incompressible vs. compressible data.
Can someone clarify the specifics on these?
I know the SandForce 22xx SSDs suffer (drastically) when writing incompressible data, but what is it?
If you use a SSD (or pair on RAID 0) as a boot/OS drive, why should it matter? Once the OS is installed, how much incompressible data is written to the drive?
I know that "media files" (music, movies) are mostly incompressible (because they are already compressed), but what else. I don't copy large files TO a SSD if its a boot drive!
If one has HDDs for Data/Media and Back Ups (like I do), but the pagefile (never used with 8GB of RAM), internet cache, and temp folders are on the SSD (and why wouldn't they be), how much data is written to the OS drive? If my Excel, Word, Quicken and Media files are on a HDD, so what?
Is it enough of a factor to not get a SandForce 22xx SSD, but get a Samsung or Cruical SSD?
I know there are alot of flameboys against SF22xx controlled SSDs, I'm not one of them.
Even after reading the article several times, I'm leaning towards a (couple) OCZ Vertex 3 120GB MaxIOPS SSDs, even though the article was not about them.
I don't think that an OS drive has to fear all that much from compression issues. My reason for avoiding that kind of drive is that it makes the firmware a lot more complex and therefore more prone to bugs that could cause data loss. But that's just me - I value reliability more than performance.
See if I can answer your question on compressionable ves NON in less than 50k words.
Any and all data, be it a executable program, a photo, or a movie / audio clip is nothing but a series of 1's and 0's stored on a drive. Compression rate of a file depends on how repedative the 1's and zero's are and the algorthium doing the compression.
Using a photo (identical but one in bitmap form, the other in jpeg.). Take a picture that is just solid yellow (say 8 x10 hig res) the Bitbap will be large as each pixel is stored, but since there is a Very high repetition the corresponding jpeg is very small (note you can control the algortium manually). But as the picture becomes more complex, the Bitmap file size does not change (Each pixel is still each pixel), but the jpeg file will grow as the more complex, the fewer repeditive "patturns" of 1's and 0's
For Boot drive + programs, executable files are amost noncompressable, while files that the program calls such as a bitmap may be readily compressed. The ratio of files on the OS drive would be heavily weighted to non-compressable hense a Benchmark on a OS drive is closer to real life when say AS SSD is used vs a benchmark that uses data that is readly compressable. Benchmark using non-compressable data is not accurate either as some files on the OS are compressable - Just closer to real life. PCMark vantage benchmark is the closest to real life, but here the difference becomes the User and how he/she interfaces with the computer.
In real life (scre$%# Benchmarks) there is very little difference between the high end SF22xx and the marval based, and now throw in the Samsung controller based SSDs. It then boils down to reliability and user problems and it is in both these catagories that the SF22xx take a BACK seat.
I will not buy an OCZ product, BUT that is the company management which is in my opion - to Heck with the consummer, and I can not support that mentality!!! I may buy a SF22xx based SSD, Just not OCZ!
Anyway hope I helped on what and why on compressability vs non compressability.
sminlal: Howdy. It's been a while! I see your point. You could say you prefer quality over quantity. "Prone to bugs" is probably why the SandForce 12xx controllers had such a problem with drive throttling. And the SF22xx weren't really good until the FW2.15 update.
RetiredChief: Howdy to you too! I didn't think that the OS files would be incompressible, but that's why I asked. I know OCZ used the ATTO benchmarks on their packaging, and many SSD give horrid results on the AS SSD bench, because it uses incompressible data. I guess AS would be more real-world stats.
Yes, been awhile
1) generally executable files do NOT compress very much - Very little repeditive 1,s and zero's. You can get an idea on percentage by comparing the "zipped" file to the orginal file size. Zipped downloads - often used when "package" contains several files in which some files do compress, For zipped .exe and .dll files zip is used to prevent the file from auto runing as in walware.
2) Yes, while AS SSD is NOT real life, it is closer.
generally executable files do NOT compress very much - Very little repeditive 1,s and zero's
I'd disagree with this. I ran a test, using WinRAR to make an archive of almost 2,000 exe and dll files in the Windows\System32 folder using "normal" compression. The orginal 750MB's worth of files when compressed produced an archive file that was only about 250MB in size - that's a 3:1 compression ratio. No, it's not as compressible as, say, a text document typically is. But it's still pretty compressible, IMHO.
^ You are correct when dealing with a LARGE number of files - reason disk compression is some times used.
Not sure, but there may be a big difference when you Zip a large Number of exe/dlls as opposed to a single exe/dll. The zip program will look at all the files collectively. But when reading indivdual files such as loading the operating system and/or an individual programs file, are read individually, not collectively.
I'm not sure what you're getting at in terms of there being a difference between compressibility of all the files in the folder vs. individual files. Zip programs typically analyze each file independently in order to determine the best compression algorithm - what works well for a text document doesn't necessary work well for an EXE program.
The average size of the files I archived from the Windows folder was 500K - that's around a thousand 512-byte sectors. On the average, given the compression ratio I saw when I ran my test, an SSD using compression should be able to reduce their size to less than 400 sectors each.
I just tried archiving some small and large individual EXE and DLL files and the archive files for them really do end up between 50% and 25% of the original size.
That's why I suggested to foscooter that he shouldn't really worry about the files on the OS drive being "incompressible". Of course the OS drive has plenty of stuff other than just EXE and DLL files, but I'd be very surprised if very much of it wouldn't compress.