On Wed, 11 Dec 2019 at 21:57, Mauricio Tavares <raubvogel@xxxxxxxxx> wrote: > > So I am trying to figure out why a hard drive I am testing using fio > is not getting the same specs as the official ones. Hard drive in > question is https://www.intel.com/content/www/us/en/products/memory-storage/solid-state-drives/data-center-ssds/dc-p4500-series/dc-p4500-4tb-aic-3d1.html It's hard to say much without seeing your fio line and output but even then it would be best to know what command line/job file Intel used (if they did in fact use fio). > 1. When it says "Random Read (100% Span)", does that mean > rwmixread=100 reads while "Random Write (100% Span)" gives > rwmixread=0? Likely yes (or you could just not use rw=randrw rwmixread=<foo> and just use either rw=read or rw=write) but only Intel know for sure. > 2. Is there a way to find out the other settings they used? Looking at > https://software.intel.com/en-us/articles/evaluate-performance-for-storage-performance-development-kit-spdk-based-nvme-ssd#inpage-nav-3 > they recommend for this hard drive > > Intel SSD DC P4500 series: numjob=2, iodepth=256 > > I do not know if that is for their spdk perf program or also fio. But > further down on the same page they are talking about different > blocksizes and iodepths for testing for IPS, bandwidth, and latency > than the ones they recommended for the P4500 drive. You'll have to ask them (maybe via the spdk mailing list - https://lists.01.org/hyperkitty/list/spdk@xxxxxxxxxxxx/ ). I'll note that page also says: > Why is the performance obtained by perf better than that of fio? > > The biggest difference between the two tools is that fio is integrated with Linux* fio tools so that it can test SPDK devices with the fio_plugin engine. However, due to the problem of fio's own architecture, SPDK can't be fully utilized. And the whole application framework of fio still uses its own architecture instead of SPDK application framework. > > [...] For example, in the thread model just mentioned, in perf, the thread model provided by DPDK is used to bond the CPU core to the thread by using CPU affinity, which is no longer subject to kernel scheduling. Therefore, the advantage of asynchronous lock-free can be fully exploited. This is why the performance measured by perf is higher than that of fio, especially when using a single thread (single core) to test multiple disks at the same time. It's worth noting that fio can also "bond the CPU core to the thread by using CPU affinity" (see https://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-cpus-allowed ) so there's probably more than is covered by that sentence. Dedicated tools will always be able to beat fio but it would be nicer to have a fuller explanation... > > And that confuses the hell out of me. =) > > They also mentioned preconditioning the hard drive. How is that done? Preconditioning is done to reduce the impact of accidentally comparing a "full" SSD (which will likely have a lot of garbage collection to do) to an empty one (which should have very little garbage collection to do). https://www.google.com/search?q=ssd+preconditioning turns up some good links about it: https://www.snia.org/sites/default/education/tutorials/2011/fall/SolidState/EstherSpanjer_The_Why_How_SSD_Performance_Benchmarking.pdf and https://www.seagate.com/gb/en/tech-insights/lies-damn-lies-and-ssd-benchmark-master-ti/ give a good background and https://www.snia.org/sites/default/files/technical_work/PTS/SSS_PTS_2.0.1.pdf goes into great detail. -- Sitsofe | http://sucs.org/~sits/
