Kingston NV3

[Vincero]

I don't get this product launch...
It's performance difference to the NV2 is minor and it's specs are not really much different to some of the other NV2 variants apart from headline transfer rate numbers (which it will only get from SLC cache)...

This would just seem like another NV2 variant on any other day....

Just launching an NV3 product seems to be more marketing / "look we have something new"...
Kingston are wasting everyone's time, especially if/when they swap out hardware on this and bring it's performance profile down to what other NV2 drives could manage...

I feel sorry that @W1zzard had to waste time reviewing this...

 

[Knight47]

Are you aware of any faster QLC drive?

Maybe the Patriot Viper VP4300Lite 4TB that got swapped to QLC?

 

[bonehead123]

Websites used to call out shady bait-and-switch and now it's happening seemingly constantly without companies caring about it - it would serve well to remind people that it's happening and in the case of the NV3 Kingston don't even publish any real specs for the drive. They can switch to any old garbage next week and it won't even fail to meet their specs because their spec table is so light on info it may as well be useless: https://www.kingston.com/unitedkingdom/en/ssd/nv3-nvme-pcie-ssd

^^THiS^^

bait & switch (from any vendor) = auto no buy #1 for me

QLC + no dram = auto no buy #2 for me...

#WD4ME4EVA#

 

[_roman_]

These tests are most likely done on a fresh drive. I really wonder how the performance is with alternative non Windows environment with non Windows file system and structure after 2 or 3 years of daily usage.

In my point of view SATA should be faster with a proper drive. This drive is a waste for an NVME slot.

 

[Wirko]

These tests are most likely done on a fresh drive. I really wonder how the performance is with alternative non Windows environment with non Windows file system and structure after 2 or 3 years of daily usage.

Why would non-Windows be better or worse than Windows in that regard? As long as the OS can send TRIM commands, it's all fine. The exception might be some RAID setups where trim doesn't work.

 

[Uns1gn3d_C0d3]

These tests are most likely done on a fresh drive. I really wonder how the performance is with alternative non Windows environment with non Windows file system and structure after 2 or 3 years of daily usage.

In my point of view SATA should be faster with a proper drive. This drive is a waste for an NVME slot.

Am I reading this correctly?

If i write 100GB to the drive daily for 5 days, I would get great speeds. On day 6 and beyond, writing that same 100GB daily would be slow as molasses?

 

[Shrek]

No, because there would be time to rebuild a new (albeit smaller) SLC cache

 

[chrcoluk]

At least the review sample is QLC this time, but the issue remains that there are something like 50 known variants of the NV2 using an absolutely staggering number of different controllers and NAND for a 'single' product model.

It's just a dice-roll and you have to expect rock-bottom performance at a rock-bottom price. If the one you buy isn't as dreadful as you expected, then count that as a win. Whatever you do don't pay as much as superior drives using known controllers and NAND. Regional pricing variance is huge in the SSD market but here in Western Europe the WD SN580 continues to be priced similarly to the NV2 despite being a stellar performer that's guaranteed by WD to have the stated controller and guaranteed to be TLC NAND, even if it's not the exact TLC variant originally sampled.

I was thinking the same, usually kingston wouldnt roll out QLC until after review batch manufacturing run.

 

[W1zzard]

If i write 100GB to the drive daily for 5 days, I would get great speeds. On day 6 and beyond, writing that same 100GB daily would be slow as molasses?

what @Shrek said. When idle, the drive will flush SLC cache to TLC, freeing up more capacity in the SLC cache for incoming writes

 

[Uns1gn3d_C0d3]

what @Shrek said. When idle, the drive will flush SLC cache to TLC, freeing up more capacity in the SLC cache for incoming writes

Okay. The write speed over time notation on the graph had me confused. Thanks.

 

[b1k3rdude]

Are you aware of any faster QLC drive?

Just a cursory glance, I WAS going say this one (MP44, non q/s), but I see Teamgroup are pulling the same crap as other manufactures with the the old 'lets confuse the customer with very similar model names bull$it' the MP44 is good all-round drive, the MP44Q/S models are just as useless as the Kingston NV3.

- https://www.techpowerup.com/review/team-group-mp44s-1-tb/6.html

 

[Wirko]

Just a cursory glance, I WAS going say this one (MP44, non q/s), but I see Teamgroup are pulling the same crap as other manufactures with the the old 'lets confuse the customer with very similar model names bull$it' the MP44 is good all-round drive, the MP44Q/S models are just as useless as the Kingston NV3.

- https://www.techpowerup.com/review/team-group-mp44s-1-tb/6.html

If it has a Q in the name, guess what it means?

Edit: mostly. The Lexar NQ790 is TLC, at least the variant in the TPU database.

 

[W1zzard]

Okay. The write speed over time notation on the graph had me confused. Thanks.

Hmm ..good point .. any thoughts on how to reword to explain what is being tested? Now that you mention it, we really don't need "time"

 

[Chrispy_]

Hmm ..good point .. any thoughts on how to reword to explain what is being tested? Now that you mention it, we really don't need "time"

"Write speed over percentage of disk filled"?

Per-GB written is useful for this particular capacity of drive, but presumably the same pSLC cache ratios apply to all capacities using this controller and firmware - so a percentage filled makes as much sense and is perhaps easier to understand? The difference is minimal as people can likely work it out either way.

 

[W1zzard]

"Write speed over percentage of disk filled"?

The chart is intentionally not percentage but GB, so it's clear what the sizes are

 

[Chrispy_]

The chart is intentionally not percentage but GB, so it's clear what the sizes are

Fair enough (edited above as you were replying).

I think you're right - just drop the time element.

 

[ymdhis]

The 980 pro 'would' have been an alternwtive drive, but I was wary of the firmware issue with the 980/990 series drives -

I'm using a 980pro and a 990pro with latest firmwares and I'm not seeing any issues.

 

[W1zzard]

"Write speed over percentage of disk filled"?

Doesn't that suggest even more what @Uns1gn3d_C0d3 suspected? i.e. it would suggest that when the drive is 50% full, write speeds will _always_ be 200 MB/s (and not only when you've written 1 TB in the last 10 minutes or so)

 

[Chrispy_]

Doesn't that suggest even more what @Uns1gn3d_C0d3 suspected? i.e. it would suggest that when the drive is 50% full, write speeds will _always_ be 200 MB/s (and not only when you've written 1 TB in the last 10 minutes or so)

People hopefully understand that these tests are always sustained writes starting from an empty drive. It's the only scenario where the data is valid and in the real world, the drive is never empty and the writes aren't usually sustained for hundreds of gigs at a time without a TRIM operation or idle time to let the drive rewrite data from pSLC to more space-efficient QLC pages.

Maybe I'm wrong but perhaps a more relevant horizontal scale would be "remaining free space" as if the drive is 40% full, and you start sustained sequential writes to the drive, you're going to have the remaining free space used in pSLC mode for a similar 25% of the remaining free space before the NAND is 100% full and the controller needs to start rewriting pSLC into QLC on the fly. The graph results would look similar or identical whether you started with 1.2TB of free space or 500GB of free space, no?

 

[W1zzard]

or identical whether you started with 1.2TB of free space or 500GB of free space, no?

No, SLC cache is typically a percentage relative to free capacity. So starting with 85% disk full, even if it's all tucked into QLC will not be able to give you more than 77 GB SLC cache (2048 * 0.15 = 307 / 4 = 77 GB)

 

[Shrek]

Hmm ..good point .. any thoughts on how to reword to explain what is being tested? Now that you mention it, we really don't need "time"

Might want to make it clear (on the plot) that the drive is being denied the time it would like to pack stuff.

 

[Uns1gn3d_C0d3]

Hmm ..good point .. any thoughts on how to reword to explain what is being tested? Now that you mention it, we really don't need "time"

Agreed. Sequential write speed. Fill whole drive.

Something along those lines.

 

[Wirko]

Hmm ..good point .. any thoughts on how to reword to explain what is being tested? Now that you mention it, we really don't need "time"

You also had these comments in your past reviews. Although you didn't specifically benchmark SLC cache recovery, these clauses helped understand what was going on in the SSD:

"Pausing the stream of incoming data will of course restore full write speeds, because the SLC cache has time to flush itself to TLC." -NM710
"When write activity stops and the SLC cache has had time to free up some capacity, full write rates are restored even if the drive is partially filled." - SN770

 

[W1zzard]

You also had these comments in your past reviews. Although you didn't specifically benchmark SLC cache recovery, these clauses helped understand what was going on in the SSD:

"Pausing the stream of incoming data will of course restore full write speeds, because the SLC cache has time to flush itself to TLC." -NM710
"When write activity stops and the SLC cache has had time to free up some capacity, full write rates are restored even if the drive is partially filled." - SN770

Indeed, and subconsciously I assumed everyone would be aware of the mechanics by now

 

[Shrek]

We are not all wizards, some of us are ogres