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?!

 

[JarredWaltonGPU]

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?!

Get TestFileCreator.exe and use that to make the initial file. On HDDs, that's all you need to do. On SSDs, create the file then make a copy of it. (You could also copy it to a different drive and then copy it back if you're basically making a file that's the size of your partition.) But letting Iometer generate the file itself takes forever and a day. LOL

https://github.com/oberstet/scratchbox/blob/master/docs/iometer/Measuring IOPS using IOMeter.md

 

[evermorex76]

Anybody still interested in further testing? I did it anyway and will continue but no point posting if nobody wants to see it. I already ordered one more inexpensive drive (Patriot P400 Lite with InnoGrit controller) but I can't spend more money on this even though I'd do this for a week if I could, testing drives with various controllers from various manufacturers used in various drive brands (since they could tweak firmware to make the same controller behave differently).

Using testfilecreator.exe helps, as the performance of the test then is basically the same as testing an empty drive, however retesting with that same file performs the same as if IOMeter created it, since there is data fully written to it. So it lets me do 2 tests instead of 3, saving an hour+ total for testing and then waiting for cache recovery and TRIM.

 

[evermorex76]

So I could post more details, though I'm still testing as my new drives only arrived today. But the conclusion I've come to is that some drives will split the cache and some won't, and it's not consistent even by manufacturer.

The Samsung PM991 split the cache, where it would not allocate more than a partition's percentage of cache from that partition when writing to it, even if it had plenty of free space (weird, I know but I tested it a few times). AND it splits the access to the static SLC cache. So if the drive has 30GB dynamic and 4GB static, and you make two equal partitions each one can ONLY access 15GB+2GB from its own space even if there's enough free space for more. And it can then access up to 15GB (45 in TLC) from the other partition's free space, but it can't access the other 2GB static cache. So if one partition is full, writes to it can only access up to 15GB cache from the other partition and none from itself. The other partition also likewise only has up to 15GB, as long as it has 45GB of real capacity free.

The PM9B1 just didn't split the cache at all, period. I also noticed that with both Samsung drives, even though they aren't using all the drive space as cache, they begin folding immediately after the pSLC cache runs out. So it drops to the lowest speed immediately, rather than writing at native speed THEN folding if it runs out of native flash. They only jump back up to native speed once folding has finished.

The Patriot P400 Lite 500GB has 80GB pSLC cache, and doesn't start folding until it has filled up the QLC. The Crucial BX500 480GB has 50GB cache and just trash performance once it's full. I suspect that some of that is the factory-overprovisioned space between 480GB and 500GB/512GB and the rest is dynamic, so this could be considered "hybrid" like the Samsungs.

So unless every model gets tested with multiple partitions, there's going to be no way to know whether the cache gets split. In some cases, where the full drive is used for cache, it might only affect rare users that do a LOT of sustained writing, but on models that have only a small amount of cache to start with, it will potentially show up more quickly if they keep either partition too full. Of course the larger the drive, the more cache there is, in every case. Without getting multiple models from different brands that all use the same controller (but aren't just rebadged), I don't know if this is behavior that the SSD maker is able to configure via firmware or perhaps if it's hard-coded in the design of the controllers.

I think that overprovisioning is probably the best way to ensure you never run out of free space that the drive can use for cache, and you can make it large enough to ensure there's a large cache always available. I just feel like that's more effective than allocating the whole drive and having to keep an eye on whether you've left enough space for the drive to use as cache; you just automatically have to treat the drive as smaller than it is. But, that requires extra work from the user to do the overprovisioning, so it's not going to be the most common method.

I'd like to test the overprovisioning with a drive that splits the cache, but I don't have one large enough to make it easy.