Passmark diskmark innodisk m.2 128gb12/30/2023 I wanted to demonstrate what I observed and I did so by making a video. There are situations where the gen4 nmve drives will perform better than what is reflected by the diskmark test or at least I believe there are. I think the disk test could be improved is all I am saying. (I don't have a spare drive to test this right now, the 2 980's I have are currently set-up in raid0.) If disk copy operations run at those speeds wouldn't that count as a real-world situation, albeit one which may be uncommon at this time? In the near future, systems with multiple nvme drives should be much more common and copying files between system disks at 5000+ MB/s is a great performance increase. If you say the passmark test is reflecting the disks real world performance, what about copy operations between 2 nvme disks or nvme raid arrays? If I remember right, during those operations I've seen read-write rates that are in line with manufacturer claims. If you watch the top speed achieved with the passmark test and compare it to other disk tests, the passmark test nvr got the disks to perform at top speed. So background activity is also counted.ĭid you watch the video I posted? To be clear, I am not disappointed nor shooting anyone, I am pointing out something. WD claim a MB has 1,000,000 Bytes, as then their numbers look better that way.Īlso, task manager reports on all disk activity not just from the benchmark. Note that there is still some measurement differences depending on if you think a MB has 1,000,000 Bytes or the traditional 1,048,576 Bytes. 100% load on the disk and 7GB/sec performance!! real life performance this isn't our goal for today. No developer would write code to access the disk this way, but whatever. This time we use a massive block size (8MB), Asynchronous access (64 queue length), No caching and non-random data & 3 simultaneous threads. That even fast DDR4 RAM in dual channel can only just hit 7000MB/sec (with the I/O overhead of Disk API calls). What it does illustrate nicely however is the limit on the RAM cache speed. Clearly this is a bit of a poor disk test if the disk isn't even being used. Conclusion: All the data is being read from RAM and not from disk. 7432MB/sec read performance!!!īut wait ,what kind of shenanigans is this? Task manager reports 0% busy time and no disk activity. Success!! We have matched and slightly exceeded the marketing claims of WD. This time we allow caching of the disk activity (into RAM) Not so realistic, but whatever, we don't care at this point. Here we pick a massive block size (8MB), relatively small test file (5GB), and non-random data (which is easy to compress). For this we can use the " Advanced Disk Test" benchmark under the Advanced Test menu in PerformanceTest. Is better when it comes time to combine all the mark values to form the system's PassMark rating.Next we can have a look at if we can devise some unlikely scenario that will get us numbers that are close to the WD's marketing numbers. The average is then scaled up by multiplying the average with a 'magic' number in order to make the number larger. It is an straight average of the three values above. This is the number reported in the benchmark charts. Similar to the IOPS 32KQD20 test but uses 4KB blocks and a queue depth of 1. The amount of data actually transferred is highly dependent on the disk seek time. The file is read randomly a seek is performed to move the file pointer to a random position in the file, a 32KB block is read or written then another seek is performed using a queue depth of 20. Test (400 MB for non solid state drives, 800 MB for solid state drives). Disk Random Seek RW (IOPS 32KQD20)Ī large test file is created on the disk under Test conditions are otherwise the same as the read test. The file is written sequentially from start to end using a 32KB block size. The result is reported in MBytes/sec.Ī large file is written to the disk under test (400 MB for non solid state drives, 800 MB for solid state drives). Note that certain O/S features like file system compression, and settings in the PerformanceTest preferences window can alter the file size and test duration. The test uses uncached asynchronous file operations (with an IO queue length of 20). The file is read sequentially from start to end using a 32KB block size. A large test file is created on the disk under test (1 GB for non solid state drives, 2 GB for solid state drives).
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |