Silicon Power XD80 SSD Review: Mainstream Performance at Low Cost

Phison’s E12S, BiCS4 96L TLC, and a heatsink for how much???

Silicon Power XD80
(Image credit: © Tom's Hardware)

Tom's Hardware Verdict

Silicon Power’s XD80 is a solid-performing mainstream PCIe 3.0 M.2 NVMe SSD that comes with Samsung-beating endurance ratings and a heatsink, all at a low price.

Reasons to buy

  • +

    + Heatsink

  • +

    + Low-cost

  • +

    + Strong sustained write speeds

  • +

    + SLC cache recovers quickly

  • +

    + 5-year warranty and Samsung beating endurance

Reasons to avoid

  • -

    Small SLC cache

Why you can trust Tom's Hardware Our expert reviewers spend hours testing and comparing products and services so you can choose the best for you. Find out more about how we test.

The Silicon Power’s XD80 comes armed with a Phison E12S SSD controller, BICS4 TLC, and a heatsink. This combo delivers solid, cool performance at an affordable price point, making the PCIe 3.0 x4 drive a good value for those looking to save a few bucks over premium drives.

The XD80 competes against other mainstream SSDs like the Crucial P5, WD_Black SN750, and Samsung’s 970 EVO Plus. In addition, the drive features a unique design for a Phison-based SSD — it's one of only a few slim PS5012-E12S-based designs with TLC flash that still retains a single-sided M.2 form factor, even for the 2TB model.

Sean Webster
Storage Reviewer

Sean is a Contributing Editor at Tom’s Hardware US, covering storage hardware.

  • Alvar "Miles" Udell
    Would have been nice to see the PNY CS2130 2TB on the charts as well, as it's a 2TB drive right now on sale for $200 ($20 less than the SP XD80), and TH did an article on it last year but never did a followup.

    PNY Technologies CS2130 2TB M.2 NVMe SSD M280CS2130-2TB-RB B&H (bhphotovideo.com)
    PNY CS2310: Use That Empty NVMe Slot | Tom's Hardware (tomshardware.com)
    Reply
  • froggx
    On these disk reviews, why is it that the line graphs for the iometer sustained sequential write, gigabytes written don't use properly spaced values along the X-axis? By this I mean the intervals are labeled "0, 0.5, 1, 2, 5,10, 15 (minutes)" yet spaced in such a way to indicate that the amount of time between 1 and 2 minutes and the amount of time between 2 and 5 minutes is the same (which it isn't). Last time I did math the median value of the numbers 0 through 15 wasn't 2, nor does the median value of 0-2 minutes work out to 45 second.

    When graphed with equally spaced X values (based on the values at 1, 2, 5, 10 and 15 minutes as provided on the bar graph for this test), most of the drives write at a linear rate within 2 minutes of starting the test (because the SLC cache has run out by then). However, when I look at the 15 minute graph, it looks like the drives start the test slowly, then around the halfway point they all (metaphorically) rail a line of blow and the amount of data written skyrockets (not how drives out of SLC cache work). The graph for 2 minutes isn't all that much better.

    I've added the links to the 2 problematic graph images here for convenience:
    Graph Linky and another Graph Linky.
    Reply
  • seanwebster
    froggx said:
    On these disk reviews, why is it that the line graphs for the iometer sustained sequential write, gigabytes written don't use properly spaced values along the X-axis? By this I mean the intervals are labeled "0, 0.5, 1, 2, 5,10, 15 (minutes)" yet spaced in such a way to indicate that the amount of time between 1 and 2 minutes and the amount of time between 2 and 5 minutes is the same (which it isn't). Last time I did math the median value of the numbers 0 through 15 wasn't 2, nor does the median value of 0-2 minutes work out to 45 second.

    When graphed with equally spaced X values (based on the values at 1, 2, 5, 10 and 15 minutes as provided on the bar graph for this test), most of the drives write at a linear rate within 2 minutes of starting the test (because the SLC cache has run out by then). However, when I look at the 15 minute graph, it looks like the drives start the test slowly, then around the halfway point they all (metaphorically) rail a line of blow and the amount of data written skyrockets (not how drives out of SLC cache work). The graph for 2 minutes isn't all that much better.

    I've added the links to the 2 problematic graph images here for convenience:
    Graph Linky and another Graph Linky.

    I mainly used the gigabytes written data for the bar graph and throw that same data in for line graph to have another way to look at the data. The second is just a crop/zoomed-in view of the same to see the differences in cache a little easier since these are small charts. I went ahead and did some adjustments for you based on your feedback. Personally, I prefer looking at the data how I've been publishing it since it enhances the tail whip effect and SLC cache size differences, which I can more quickly differentiate, but can start throwing in this new graph instead if you prefer it.
    Do you prefer the charts on the left? I appreciate the feedback. If you have any more, let me know. Thanks.

    92
    Reply
  • Co BIY
    seanwebster said:
    I mainly used the gigabytes written data for the bar graph and throw that same data in for line graph to have another way to look at the data. The second is just a crop/zoomed-in view of the same to see the differences in cache a little easier since these are small charts. I went ahead and did some adjustments for you based on your feedback. Personally, I prefer looking at the data how I've been publishing it since it enhances the tail whip effect and SLC cache size differences, which I can more quickly differentiate, but can start throwing in this new graph instead if you prefer it.
    Do you prefer the charts on the left? I appreciate the feedback. If you have any more, let me know. Thanks.

    92


    I 'd vote for charts on the left. It's a better presentation of the information.
    Reply
  • Sleepy_Hollowed
    Wow, this is a true steal, and absolutely all you need for PC gaming.

    If I didn’t use my machine for IO intensive stuff I’d buy two of these puppies, and even then I’m considering them anyways.

    power-wise I’d need to test it a bit more on Linux to see if laptops would do well with it, but holy moly.
    Reply
  • Sleepy_Hollowed
    Wow, this is a true steal, and absolutely all you need for PC gaming.

    If I didn’t use my machine for IO intensive stuff I’d buy two of these puppies, and even then I’m considering them anyways.

    power-wise I’d need to test it a bit more on Linux to see if laptops would do well with it, but holy moly.
    Reply
  • MechGalaxy
    Does anyone have the idle power usage of these or can someone explain why the samsung 970 evo and intel 660p are so low?
    The review says just under half a watt. That seems abnormally high. It doesn't make sense given the temps and efficiencies compared to the samsung.
    In contrast the (samsung 970 evo pro) uses 30 - 72mW with ASPM on or off according to the review here Samsung 970 evo Plus.
    Reply
  • seanwebster
    MechGalaxy said:
    Does anyone have the idle power usage of these or can someone explain why the samsung 970 evo and intel 660p are so low?
    The review says just under half a watt. That seems abnormally high. It doesn't make sense given the temps and efficiencies compared to the samsung.
    In contrast the (samsung 970 evo pro) uses 30 - 72mW with ASPM on or off according to the review here Samsung 970 evo Plus.
    For lower power consumption figures ASPM needs to be enabled in the UEFI. Not all systems support toggling this in the UEFI. Therefore, we test power consumption with ASPM disabled on our latest test benches.

    Additionally, the lowest desktop idle idle state data, while important, isn’t as important as laptop idle state data. That, however takes more effort to attain and is something outside the scope of a normal review.
    Reply