Inside the Intel SSD 335

Similar to the SSD 330, the SSD 335 has a single thermal pad covering the controller. The whole case is made out of metal, so heat dissipation in general should not be an issue. There doesn't seem to be any visible differences between the PCBs of SSD 335 and 330, other than the fact that the SSD 335 loses the "BIN 2" sticker and is manufactured in fab 4 instead of fab 3 (although it's completely possible that SSD 335s are manufactured in fab 3 as well). 

The SF-2281

As usual, there are a total of sixteen NAND packages, eight on each side of the PCB. Each NAND package consists of two 8GB 20nm MLC NAND dies, making each NAND package 16GB in capacity. The new 20nm process node is indicated by the 12th character, which is an F. Process nodes follow the alphabet, meaning that F is 20nm, E is 25nm, D is 34nm and so on. 

Test System


Intel Core i5-2500K running at 3.3GHz (Turbo and EIST enabled)


AsRock Z68 Pro3


Intel Z68

Chipset Drivers

Intel + Intel RST 10.2

Memory G.Skill RipjawsX DDR3-1600 2 x 4GB (9-9-9-24)
Video Card XFX AMD Radeon HD 6850 XXX
(800MHz core clock; 4.2GHz GDDR5 effective)
Video Drivers AMD Catalyst 10.1
Desktop Resolution 1920 x 1080
OS Windows 7 x64


Testing Endurance Random & Sequential Read/Write Speed


View All Comments

  • Per Hansson - Tuesday, October 30, 2012 - link

    No, it does not work like that.
    A slow DMM might take a reading every second.
    An example, in seconds:
    1: 2w
    2: 2w
    3: 2w

    A fast DMM might take readings every 100ms:
    1: 2w
    2: 0.5w
    3: 2w
    4: 0.5w

    As you see a DMM does not take a continous reading, it takes readings at points in time and averages those...

    An SSD drive might actually change power levels much more frequently, like every millisencond (consider their performance, how long does it take to write 4KB of data as an example?)
  • hrga - Thursday, November 01, 2012 - link

    dont think SSD even try to write such a small amount of data as 4kB every milisecond considering how large buffers usually have 128GB LPDDR2. So thes kind of small writes occur in bursts when they accumulate every 15-30s (at least hope so as this was case with hard drives) That ofc depends on firmware and values in it. Reply
  • Per Hansson - Thursday, November 01, 2012 - link

    That makes no difference, I sincerely hope that no drive waits 15 > 30 seconds to write data to disk because that is just a recipe for data loss in case of power failure or BSOD.
    I also hope no drive uses a 128GB write cache. (Intel's in house controller keeps no user data in cache as an example, but I digress)

    Even if the drive waits a minute before it writes the 4KB of data you must still have a DMM capable of catching that write, which is completed in less than a millisecond.
    Otherwise the increased power consumption during the disk write will be completely missed by the DMM
  • Mr Alpha - Monday, October 29, 2012 - link

    Wouldn't it make more sense to the idle power consumption on a platform that supports DPIM? The idle power usage is mostly a matter on mobile devices, and it is on those you get DPIM support. Reply
  • sheh - Monday, October 29, 2012 - link

    The text says total writes were 1.2TB, (+3.8TB=) 5TB, and 37.8TB. The screenshots show "host writes" at 1.51TB, 2.11TB, and 3.90TB? Reply
  • sheh - Monday, October 29, 2012 - link

    And why the odd power on hours counts? Reply
  • Kristian Vättö - Monday, October 29, 2012 - link

    You are mixing host writes with the actual NAND writes. Host writes are the data that the host (e.g. an operating system) sends to the SSD controller to write. NAND writes show much is written to the NAND.

    When the SSD is pushed to a corner like I did, you will end up having more NAND writes than host writes because of read-modify-write (i.e. all user-accessible LBAs are already full, so the controller must read the block to a cache, modify the data and rewrite the block). Basically, your host may be telling the controller to write 4KB but the controller ends up writing 2048MB (that's the block size).
  • extide - Monday, October 29, 2012 - link

    Block size is 2048KB* Reply
  • sheh - Monday, October 29, 2012 - link

    So the write amplification in the end was x9.7?

    Are NAND writes also reported by SMART?

    And with the messed up power on count, how can you know the rest of the SMART data is reliable?
  • Kristian Vättö - Tuesday, October 30, 2012 - link

    Yes, write amplification was around 9.7x in the end. That makes sense because the drive becomes more and more fragmented the more you write to it.

    As you can see in the screenshots, the SMAT value F9 corresponds to NAND writes. Most manufacturers don't report this data, though.

    We just have to assume that the values are correct. Otherwise we could doubt every single test result we get, which would make reviewing impossible. The data makes sense so at least it's not screaming that something is off, and from what I have read, we aren't the only site who noticed weird endurance behavior.

Log in

Don't have an account? Sign up now