Is Sandforce "cheating" by citing read/write spec of high compressible data?

[GundamF91]

Part of the reason Sandforce controller is so fast is it compresses data when it writes it, therefore when it's read, it is in essence a smaller chunk of data. I'm not sure other SSD controllers do that, or to that extent. It seems that to get true SSD comparisons, the read/write should be on uncompressed data. Otherwise, it's not an apple to apple comparison. For non-Sandforce controllers that cannot compress data very well, you can just have Windows keep data as compressed files, and that may result in improved read/write speed.

 

[Zap]

On the flip side, a normal user will benefit from the compression, so if the drives are tested in the manner you suggest, then the Sandforce drives may end up with low numbers that do not reflect what a normal user would actually experience.

Interesting to note that for the upcoming Sandforce 2000 series controllers, the compressed and uncompressed read numbers are the same. See the "preliminary test data" from this Anandtech link.

I don't know if the same was true for the older 1200 series. Anyone?

 

[Voo]

Since any serious reviewer also tests completely random data (worst case) and most also include some more or less RL benches as well, I don't see that as much of a problem.

 

[GundamF91]

There should be a happy medium where the buyers could compare specs between different controllers/brands. The reviews are nice, but if there's some difference, then the buyer who just read the retail website listed spec would be mislead, unless they also go read reviews elsewhere

Maybe it won't matter as much down the road, as everyone use the compression more, and that incompressible writes catch up in speed.

 

[Nintendesert]

On the flip side, a normal user will benefit from the compression, so if the drives are tested in the manner you suggest, then the Sandforce drives may end up with low numbers that do not reflect what a normal user would actually experience.

Interesting to note that for the upcoming Sandforce 2000 series controllers, the compressed and uncompressed read numbers are the same. See the "preliminary test data" from this Anandtech link.

I don't know if the same was true for the older 1200 series. Anyone?

This is what impressed me the most about what Anand wrote up when he did some tests of the drive. It's actually performing up to the claims and we're not seeing a huge dropoff with uncompressable data and even the write speeds are huge.

It looks like a big winner from everything seen so far.

 

[Emulex]

at some point the compressor becomes the bottleneck. i suspect that is what you are seeing. again if you had two sandforce 1200's in raid - might that be more powerful since it two compressor engines?

 

[Old Hippie]

It seems that to get true SSD comparisons, the read/write should be on uncompressed data. Otherwise, it's not an apple to apple comparison.

Very true.

I use AS-SSD as an apple-to-apple test.

I feel SF and it's partners are being very slick with those "special circumstance" speeds and they are misleading uneducated consumers.

The drives aren't bad but only perform exceedingly well on paper.

This type of marketing tactic pretty much sours me on anything OCZ but not to the point of being an anti-fanboy.

I just doubt anything they say.

 

[GundamF91]

Maybe what's to do proper reviews of SSD to always do quote for compressible and incompressible data. For the incompressible data test, they could use a GB or two of data that is already highly compressed, such as tightly packed RAR, and/or Xvid AVI files. Showing both types of speeds should present better information on whatever controller may do to the files, at least until there's a point that the speeds become similar like in SF-2000

 

[Old Hippie]

Maybe what's to do proper reviews of SSD to always do quote for compressible and incompressible data.

Does it matter?

SF says their drives are not to be used with AS-SSD because it takes too long to recover. That's pretty much major BS to me. If SF drives have to recover from a particular test then mabe they need a pacemaker or Oxygen mask?

AAR, I seriously doubt it would matter. Everyone will look for the highest STR regardless of the test and go from there.

Kinda like

You can lead a horse to water, but you can't make it drink

.

There's no way you're going to educate the masses and I'm pretty sure some can't/won't be educated anyway.

 

[Mark R]

SF says their drives are not to be used with AS-SSD because it takes too long to recover. That's pretty much major BS to me. If SF drives have to recover from a particular test then mabe they need a pacemaker or Oxygen mask?

It's not quite BS.

AS SSD random 4k writes are extremely stressful for the SSD. The large number of random writes means that you end up with high levels of internal fragmentation and partially written blocks on the SSD's flash. This means that wear leveling must kick in very early, and then the performance degrades (until the drive is TRIMmed or its internal garbage collection optimized the free blocks and pages).

The problem with very aggressive garbage collection is that it increases write amplification - similarly, many drives ignore TRIM commands that are smaller than a certain size, because it isn't worth the effort processing them.

Sandforce deliberately bias their firmware to minimize flash wear, rather than optimize for performance at all times. As a result, the extremely destructive (and unrealistic) workload of AS SSD can result in prolonged periods of performance degradation. So, you can see the reason for their recommendation.

 

[Old Hippie]

So, you can see the reason for their recommendation.

I always could understand the reasoning/how the drives work and still consider it deceptive.

They're counting on the general publics ignorance of SSDs to make the drives look superior to others.

Spin it which ever way you want but I'm too old and been at the game of life to long to consider it anything else.

 

[Emulex]

a normal user can compact files or directories. compression does cost latency though

 

[Mark R]

a normal user can compact files or directories. compression does cost latency though

My understanding is that the sandforce doesn't actually compress, and instead it performs block-level deduplication. Unfortunately, we don't know for sure, because Sandforce treat this as a trade secret.

The behavior of deduplication is somewhat different to compression when it comes to manipulating files, etc. Moreover, deduplication isn't something that most workstation/desktop level filesystems perform.

Still, it should be possible through benchmarking to workout just how much is compression and how much is deduplication. When I get some time, I might put together a tool to see just how much of which is actually in use.

 

[Emulex]

well the drive has to write an ECC for the block, so if it has a hash table of blocks and it sees the same ECC twice it's probably duplicate assuming the ecc is not md5

these controllers are pretty slick. they do alot of work in the background when you have nothing in the queue to give "Turbo-boost" like speed. powerboost. however you want to call it. pretty cool if you get the datasheets and read about some of the tech.

if the free ZFS can deduplicate - and ntfs has a pretty good compact command might as well. you know the hibernation files are compressed to increase load time on osx?

 

[Voo]

well the drive has to write an ECC for the block, so if it has a hash table of blocks and it sees the same ECC twice it's probably duplicate assuming the ecc is not md5

MD5 being broken just means, that there are algorithms that allow you to find collisions more effectly than by brute force - the birthday "paradox" is true for all hash functions and for random generated values your chances of getting a collision with MD5 aren't much worse than for SHA2 (apart from the different bit sizes). So just comparing hashes is a sure way to lose lots of data (and ECCs contrary to hash functions are by design not engineered to avoid collisions).

Also deduplication in ZFS is extremely hardware intense and needs lots of RAM to be effective - both things you really don't want on a device.

 

[Emulex]

but we're talking ecc which has be to computed in hardware anyways, and it has to be tabled to do wear leveling. maybe its storing the raw sata dump with RLL encoding. it would be easy to tell if its a RLL or LZ based by altering your benchmark slightly

 

[Voo]

but we're talking ecc which has be to computed in hardware anyways, and it has to be tabled to do wear leveling.

Yeah but we only have to compute the ecc for the sector we're writing to (well no idea on which granularity level SF computes ECC) and why would we need to have a special table for ECC values, when we could as well store them with the data? One less data structure to update correctly.

But the problem that I see is, that ECCs aren't necessary collision ressistant (anyone knows which algorithm they're using? and yeah they could obviously use an additional hashing algorithm as well) and that you'd have to make a byte to byte comparision for every collision, as well as maintain a table with all entries in memory (which depending on which algorithm and granularity, could be pretty large).
ZFS recommends a whole lot of memory for their dedup tables - I don't remember any exact values, but if we can trust wikipedia on the matter that'd be 2gb RAM/1TB data.
And trying to use it in a server with a noticeable amount of writes resulted in horrible, horrible performance for me because CPU utilization just shot straight through the roof.

 

[Mark R]

But the problem that I see is, that ECCs aren't necessary collision ressistant (anyone knows which algorithm they're using? and yeah they could obviously use an additional hashing algorithm as well) and that you'd have to make a byte to byte comparision for every collision, as well as maintain a table with all entries in memory (which depending on which algorithm and granularity, could be pretty large).

Well, you have the advantage of hardware fixed-function pipelines, so you could use a hardware based hashtable - which could be hugely faster - and hardware based block comparators. Whether it is practical or not, I don't know. Sandforce don't even say how much RAM their processor has.

In terms of the ECC algorithms, they're almost certainly some type of Reed-Solomon code. However, the block and element sizes are tuned for the particular type of flash chip used (Sandforce use different ECC for different memories, because the different manufacturing processes lead to different error patterns). OEMs can then just choose their flash, and install the firmware optimized for that memory.

 

[vol7ron]

It seems that to get true SSD comparisons, the read/write should be on uncompressed data. Otherwise, it's not an apple to apple comparison.

What we need to have is a testing standard, provided by an accredited organization. It seems we need to have a large sample result-set for the year that all vendors should use to quote their numbers.

I'd like to see something spread as AT does. Something to the tune of 60%uncompressed, 40%compressed. Having the sample be something like 20GB. Of course, they could still tune their hardware to compensate, but with such a large sample it would probably be more difficult.

 

[vol7ron]

ZFS recommends a whole lot of memory for their dedup tables - I don't remember any exact values, but if we can trust wikipedia on the matter that'd be 2gb RAM/1TB data.

Perhaps you found another use for the extra spare-NAND on the drive

 

[Emulex]

i use 2GB ram for 2TB of data when doing inline deduplication for backup. that's why all the backups run at the same time. so the window of 2GB (including o/s and app) can slide with collation of the os (all 2003, all 2008) to hit on likely vmfs files that are like.

so yeah that number isn't insane. between dedupe and compress you can nuke 1.5 to 2TB to 300-500gb though which is hot!

 

[Old Hippie]

What we need to have is a testing standard, provided by an accredited organization.

Probably.

The SSD "specs" that we're seeing today remind me of the 60s-early 70s audio amps when there were various standards and most manfgs used/abused/created specific standards to make their amps the better "bargain" by having more "power on paper".

All those false specs were to confuse and sway uneducated consumers because they're were no standards. Sound familiar?

It came to an end in 1974 when the FTC got involved and most problems were resolved.

I've heard several refrences in the past about shady practices at OCZ and consider this another one.

Someone else on these forums pointed to the fact that GSkill actually posted many different test scores including AS-SSD on it's site...and it's true.

If I were to purchase a SF drive I'd be buying it from the guy/manfg who's honest about the faults and not sweep it under a rug.

 

[Emulex]

i don't get it? use it and see how it feels. honestly for most folks all the drives i've used feel the same.

Let's take core 2 duo - for the most part since 2007 the mhz really influenced the biggest "feel" of difference. A 2007 processor at 4ghz well that seemed as fast as 2009 core2duo clocked to 4ghz. So the analogy for SSD is # of chips (which at the same NM = megabytes of storage)..

a 160gb x25-m pretty much feels as fast in consumer use as a 160gb (indilinx,sandforce).

512gb definitely feel faster but not twice as fast but the diminishing returns kicks in. a raid-0 of 256 doesn't feel TWICE as fast as 1 512gb - probably because of some overhead. maybe the benchmark queens that just like to post benchmarks feel the difference but if you really did write that much to a drive you'd roach it years before its lifespan.

AS-SSD and CDM in full random are pretty good benchmarks but at the end of the day we know folks are tweaking their SSD's to put out better numbers.

I want stability first. speed could be 50% slower than the rest but if its the only drive with 100% uptime - yes please.

 

[pjkenned]

I actually like the SF drives. Sure you can create artificial loads to kill them. Real world... you won't notice.

Plus, they are actually pretty good for L2ARC. The SF-1200 60GB drives have been about $100 for a long time now. Eight of them actually work well as cache drives since L2ARC writes data fairly slowly anyway.

In fact, if you look at the 285/275 claims, one can fairly easily get them repeatedly with ATTO (incidentally this is the only benchmark for which those numbers are claimed.) It is not wrong to say you can get 250MB/s+ speeds in a benchmark if you deliver on that performance in that benchmark. At that point it is up to the consumer to do more than go blindly on NewEgg's short-form read/ write speeds.

 

[Emulex]

it's kinda like the old days when the graphics cards folks tweaked their drivers to give out faster speeds. sure its real and repeatable - but yeah everyone cried wolf!