Question How to use IOMeter like Tom's for pSLC testing ?

[evermorex76]

If there's a page already written about this, apologies and I'd like to read it. The "how we test" article doesn't mention it. I found a post from 2023 here, but nobody actually gave information on IOMeter as Tom's uses it.

What are the test methods used by Tom's for IOMeter to test the pSLC cache size? Like IOMeter configuration and how they get the complete results and graph it. I've been trying it out using the Google Overview methods (which vary depending on how you phrase the search and I hate using it but couldn't find anything else), but it's very simplistic.

There are references to things like "block size" that simply don't exist in the IOMeter GUI, and they recommend "multiple gigabytes" but "transfer request size" only allows up to 1023MB,1023KB,1023B. There are also only a few datapoints in the results.csv file, so I don't see how it's possible to graph out all the speeds at each amount of data written. I'm also getting ridiculous results, like 400MBps to 550MBps sequential on a drive that benchmarks at 1.7GBps writes.

 

[evermorex76]

So thanks to @JarredWaltonGPU in this thread, I was able to test pSLC cache. https://forums.tomshardware.com/thr...rs-and-heres-how-they-stack-up.3827997/page-4

I found something I think is very interesting, that doesn't get tested in reviews. BTW yes I have AuDHD so this is something I hyperfocused on and a long read.

tl;dr: Splitting an SSD into multiple partitions results in the pSLC cache size for each partition being split proportionally as well.

SO! This is interesting to me, and not what I expected. I wanted to test how pSLC is affected by partitioning, because the tests that are performed are only done on empty drives in reviews. I bought a new Orico e7400 500GB drive (476 binary) for my laptop, and before putting it in, I tested it in my desktop, an X570 board with the drive connected to a PCIe adapter in an x4 slot via the chipset (which seems to cause some limits as it does not reach the max read speeds).

Testing the full, unformatted drive shows it uses the full space for pSLC, with 4800MBps up to 125GB, which is exactly right for a QLC 500GB drive. Then it drops to about 860 for a long while, even peaking at 900, which seems to be where it is folding while writing, which is a pretty big drop. Eventually the folding seems to fall behind, as it drops down again to about 400, direct to QLC speed. Then after 3 minutes exactly, it jumps back up to the 800 range and stays for the rest of the test, 30 minutes total. I wonder if a longer test would show it repeatedly going through these short periods where the folding seems unable to keep up. Still, pretty good for a cheap QLC drive I think, and great for my laptop usage. The speeds do have a lot of random very low points which then jump back up to normal (like 500MBps slower at times) but it's mostly within acceptable variance.

Then I tested with the drive formatted with one full partition. IOMeter fills the drive with a data file for this (I haven't investigated why it needs to), so essentially there are zero free blocks to be used as pSLC cache, and it writes around 860 through the entire drive.I would have expected it to hit 400 since there's no space to use as cache and no space to fold anything out, but maybe it's actually got some overprovisioning for this.(IOMeter doesn't report the speed while it is generating the test file, which WOULD show the pSLC speed and the drop due to folding, I'm sure.)

Then I shrank the partition to 250GB. This time, the pSLC cache ran out at only 62! That's half the cache size available, matching the partition percentage. The drive does NOT use all that unpartitioned space as a pSLC cache area. It only uses the space proportional to the size of the allocated partition. I would have expected it to just use translated addressing for that entire 250GB of unpartitioned space to use it as pSLC then fold it over to the normally addressed QLC blocks after all the work was done. I guess perhaps this avoids the possibility of the space being in use when the user tries to immediately allocate it and write to it immediately after having filled the first partition, but that seems like an unlikely scenario and would otherwise just result in it writing new data while folding. It also showed a similar drop to native-QLC speed then back to 800-ish as the unformatted drive did (but the full partition did not), but it happened immediately after the cache ran out and lasted 1 minute exactly.

Then I tried it with two partitions filling the drive. The two both performed the same as the single smaller partition, so having that second half allocated seems to have made no difference.

So for anyone that partitions their drives, you are in fact reducing the potential performance of your SSD within each partition because each one has proportionally less pSLC cache space. This would really screw with Samsung drives which have a limited amount of dynamic pSLC cache in the first place rather than using the whole drive, or a smaller drive like 250 or 500GB. If you've got a 1TB Samsung drive and make two equal partitions, you go from having 240GB of cache to only 120 for each partition. If you're the type that likes to make a small partition for the OS (say 120GB and then a large partition for data and games, the Samsung drive would give you only 28.8GB of pSLC cache on the OS (which you might not notice since most of your large files would be going to the second partition, but it would depend on your usage, and Windows loves putting everything in Documents and Downloads and the like).

 

[JarredWaltonGPU]

So thanks to @JarredWaltonGPU in this thread, I was able to test pSLC cache. https://forums.tomshardware.com/thr...rs-and-heres-how-they-stack-up.3827997/page-4

I found something I think is very interesting, that doesn't get tested in reviews. BTW yes I have AuDHD so this is something I hyperfocused on and a long read.

tl;dr: Splitting an SSD into multiple partitions results in the pSLC cache size for each partition being split proportionally as well.

SO! This is interesting to me, and not what I expected. I wanted to test how pSLC is affected by partitioning, because the tests that are performed are only done on empty drives in reviews. I bought a new Orico e7400 500GB drive (476 binary) for my laptop, and before putting it in, I tested it in my desktop, an X570 board with the drive connected to a PCIe adapter in an x4 slot via the chipset (which seems to cause some limits as it does not reach the max read speeds).

Testing the full, unformatted drive shows it uses the full space for pSLC, with 4800MBps up to 125GB, which is exactly right for a QLC 500GB drive. Then it drops to about 860 for a long while, even peaking at 900, which seems to be where it is folding while writing, which is a pretty big drop. Eventually the folding seems to fall behind, as it drops down again to about 400, direct to QLC speed. Then after 3 minutes exactly, it jumps back up to the 800 range and stays for the rest of the test, 30 minutes total. I wonder if a longer test would show it repeatedly going through these short periods where the folding seems unable to keep up. Still, pretty good for a cheap QLC drive I think, and great for my laptop usage. The speeds do have a lot of random very low points which then jump back up to normal (like 500MBps slower at times) but it's mostly within acceptable variance.

Then I tested with the drive formatted with one full partition. IOMeter fills the drive with a data file for this (I haven't investigated why it needs to), so essentially there are zero free blocks to be used as pSLC cache, and it writes around 860 through the entire drive.I would have expected it to hit 400 since there's no space to use as cache and no space to fold anything out, but maybe it's actually got some overprovisioning for this.(IOMeter doesn't report the speed while it is generating the test file, which WOULD show the pSLC speed and the drop due to folding, I'm sure.)

Then I shrank the partition to 250GB. This time, the pSLC cache ran out at only 62! That's half the cache size available, matching the partition percentage. The drive does NOT use all that unpartitioned space as a pSLC cache area. It only uses the space proportional to the size of the allocated partition. I would have expected it to just use translated addressing for that entire 250GB of unpartitioned space to use it as pSLC then fold it over to the normally addressed QLC blocks after all the work was done. I guess perhaps this avoids the possibility of the space being in use when the user tries to immediately allocate it and write to it immediately after having filled the first partition, but that seems like an unlikely scenario and would otherwise just result in it writing new data while folding. It also showed a similar drop to native-QLC speed then back to 800-ish as the unformatted drive did (but the full partition did not), but it happened immediately after the cache ran out and lasted 1 minute exactly.

Then I tried it with two partitions filling the drive. The two both performed the same as the single smaller partition, so having that second half allocated seems to have made no difference.

So for anyone that partitions their drives, you are in fact reducing the potential performance of your SSD within each partition because each one has proportionally less pSLC cache space. This would really screw with Samsung drives which have a limited amount of dynamic pSLC cache in the first place rather than using the whole drive, or a smaller drive like 250 or 500GB. If you've got a 1TB Samsung drive and make two equal partitions, you go from having 240GB of cache to only 120 for each partition. If you're the type that likes to make a small partition for the OS (say 120GB and then a large partition for data and games, the Samsung drive would give you only 28.8GB of pSLC cache on the OS (which you might not notice since most of your large files would be going to the second partition, but it would depend on your usage, and Windows loves putting everything in Documents and Downloads and the like).

I didn't see your original question here, sorry. But it should be noted that what you saw in testing may only apply to certain SSDs. (I don't actually know, as it's not something I've previously investigated.) So your specific controller may do things one way, while some other controllers might work more as you expected when partitioning.

 

[evermorex76]

Yeah now that I know how it works, I'm playing with others. I'm testing a really crappy OEM Samsung drive right now, and I have a better Samsung I'll be able to test after I pull it from the laptop tomorrow, and an SN550 maybe. Digging into specific controllers is beyond my interest, but if I find 2 big names and Orico act the same way, I'll assume they all do.

Mental illness and ADHD meds go great together for getting things done.

OMG 150MBps writes on a 256GB drive being filled with a test file! How did we survive with mechanical drives?!