Random & Sequential IO Performance

Similar to our other Enterprise Iometer tests, queue depths are much higher in our Iometer benchmarks. To measure sequential performance I ran a 1 minute long 128KB sequential test over the entire span of the drive at a queue depth of 32. For random performance, I ran a 3 minute long 4KB random read test over the entire span of the drive at a queue depth of 32. Random write performance was measured at steady state (QD32), which varies depending on capacity and other factors. The results reported are in average MB/s over the entire test length.

Enterprise Iometer - 4KB Random Read

Random read performance is just excellent. The S3500 gives up nothing compared to the S3700 and ends up being one of the fastest enterprise drives we've tested.

Enterprise Iometer - 4KB Random Write

Random write performance takes a big hit compared to the S3700. At 47MB/s, the S3500 isn't bad but it's not class leading like the S3700.

Enterprise Iometer - 128KB Sequential Read

Sequential read speed is limited by 6Gbps SATA, and the S3500 has no issues hitting that limit given the number of NAND die inside the 480GB model. It's not until you get down to the 160GB version that performance will drop below 500MB/s.

Enterprise Iometer - 128KB Sequential Write

Sequential write performance is substantially better on the S3500, making this drive even better for large sequential caching applications.

Performance Consistency Final Words
Comments Locked

54 Comments

View All Comments

  • Minion4Hire - Tuesday, June 11, 2013 - link

    I believe that's just the writes they guarantee the drive for. There's write amplification and maintenance to consider there as well.
  • ShieTar - Wednesday, June 12, 2013 - link

    Well, they have to keep the S3700 useful enough to sell both. So they tailor the specs a bit in order to push customers into buying the "right" drive.
  • ShieTar - Wednesday, June 12, 2013 - link

    Then again, if this is guaranteed for the whole range, its an impressive number for the small 80GB drive.
  • pesos - Tuesday, June 11, 2013 - link

    How about performance over time in virtualization scenarios? Wondering how well these SSDs hold up when they have nothing on them but virtual hard disks...
  • dealcorn - Tuesday, June 11, 2013 - link

    In Part 2, could you kindly note whether the Drive supports DEVSLP. Depending on usage pattern, not considering the drive for mobile use based on idle power requirements may be inappropriate.
  • sunbear - Tuesday, June 11, 2013 - link

    Looking at the consistency comparison against the seagate 600 pro, it looks like the intel s3500 is more consistent but unfortunately it's consistently slower in every metric. I'd rather have a seagate 600 pro with inconsistent performance if the minimum performance if that drive is better than the maximum performance of the s3500.
  • beginner99 - Wednesday, June 12, 2013 - link

    I had the same thought. agree.
  • hrrmph - Friday, June 14, 2013 - link

    As an individual drive maybe.

    For RAID, the slowest drive in the array will probably control the overall I/O rate. In that case, I don't see an advantage for Seagate over Intel.

    As I see it, the S3500 is a pro-sumer high-end workstation drive for RAID arrays, and a mid-range enterprise class drive. The S3700 is clearly a full-on high-end enterprise class drive.

    We'll have to wait for Part 2 of the article and hope that Anand gives us some comparisons to the consumer 520 series to see if there is any reason to buy an S3500 instead of a 520.

    Intel is being suspiciously quiet about the upcoming 530 series SSDs. I expect that we'll be looking at another low power consumption, high performance, relatively affordable SSD using a non-Intel controller. But, it would be nice if we could have all of that with an Intel controller instead.

    -
  • rs2 - Wednesday, June 12, 2013 - link

    What's the deal with the first slide from Intel shown in the conclusion? Specifically, how is a 12x800GB (9.6 TB) deployment comparable to a 500x300GB (150 TB) deployment?

    The only way you can get 500 VM's on such a deployment is if you allocate only ~20 GB per VM. That's anemic. And if that's the allocation size then the 500x300GB can support over 7500 VM's.

    So...yeah, not seeing how a valid comparison is being made. Intel should be quoting figures based upon ~192 SSD's, because that's how many it takes to reach the same storage capacity as the solution it's being compared to.
  • flyingpants1 - Wednesday, June 12, 2013 - link

    I noticed the same thing.

Log in

Don't have an account? Sign up now