1. For 25fps playback of 2k 10bit DPX files the technical minimums are:
   • 25 guaranteed I/O transactions per second for a total request size of 12MB per transaction
   • Minimum latency per I/O better than 40ms
   • Sustained read bandwidth across array, minimum of 301MB/s
     
     
2. This is the absolute minimum that MUST BE sustained at all times.
   • 48 guaranteed I/O transactions per second for a total request size of 8.4 to 12MB per transaction
   • Minimum latency per I/O better than 20ms
   • Sustained bandwidth across array for dual stream operation at 24fps per stream, minimum of 577MB/s

The Benchmarking Process:

1. Get the tools
   APL uses I/Ometer to simulate the SCRATCH load on a storage subsystem. Download the latest version of I/Ometer from www.iometer.org for your tests. A configuration file that generates a range of access specifications for recreating the behavior of SCRATCH can be downloaded here. Use the most recent version of the config file available. Older versions of theconfig file are kept on this site for archiving purposes only. When submitting your results, clearly state which version of I/Ometer and which version of the configuration file you have used.

   Note: Please ensure that any virus scanning and remote desktop software you may have on the system is disabled during benchmarking.

2. Run the Tests
   Once you have acquired I/Ometer you can load the configuration file into it and begin your test. While IO meter gives you the option to run its test directly on the disk you must always run the benchmark on a logical volume, i.e. the volume that maps to your storage array. The icons for such volumes are yellow.

SCSI/Fibre Channel
I/Ometer will create a file "iobw.tst" on the volume which may take some time depending on the size of the array. Make sure this file fills the entire space on the volume. There should be no other files on the array during testing. Please refer to the user manual for I/Ometer for more background information.

SATA
The prerequisites, such as use of the logical volume rather than the individual disks, are the same as for SCSI storage mentioned above. However, due to the more pronounced manifestation of the cliff effect (the loss of performance at the end of the disk) some additional testing will be required depending on the configuration.

• If you storage solution contains 12 drives of the "300GB or larger" generation, no further action is required and testing requirements are the same as for SCSI based systems.
• If your storage solution contains less than 12 drives you will need to run a dedicated test on the slowest 10% of the drives. If the loss performance in this area of the array is significant enough to potentially prevent real-time playback APL with post such a note with the results to manage customer expectations.

The testing of the last 10% is achieved by off-setting I/Ometer's test area on the "iobw.tst" test file after the first batch of tests has been run. It is important that the "iobw.tst" file fills up the entire array. You will need to calculate the total number of 512 byte sectors contained in the "iobw.tst" file based on its size. You then need to subtract 10% from this value and use the resulting sector value in the "Starting Disk Sector" field in the "Disk Targets" tab of I/Ometer user interface. Please refer to the I/Ometer manual for further background information.

It's permissible to artificially reduce the usable size of your drives -- as for example supported by some SATA RAID enclosures, to reduce the amount of "cliff" -- as long as this is documented when submitting the results and the tested configuration is actually available for purchase by customers. In such a situation when the size reduction is by 10% or more per disk the storage can be tested like SCSI products.

For testing on SANs, a basic high-level architecture drawing should be submitted with the test results. This drawing will be published with your results. For mutli-seat DI installations, each seat on the SAN should simultaneously run the APL I/Ometer test.

Other conditions may apply, since SAN installations are usually custom designed, please contact the ASSIMILATE PERFORMANCE LAB at apl@assimilateinc.com to discuss your planned test.

• Using the "record all" setting on the "test setup" tab of I/Ometer, record the test results into a ".csv" file. The filename should follow this format "companyname_productname_date.csv". If you were required to run a second test on the slowest 10% of the array then add "_last10" to the name of the ".csv" file associated with this test. When testing always ensure that the "iobw.tst" file, the I/Ometer workfile, completely fills up each partition. This file is generated during the first test run of I/Ometer and the process can take some time.
• Zip up all ".csv" files into one file. This zip file should contain the vendor and product name and test date in the file name. Include a description, such as model number, RAM, processor count and speed, of the host workstation used for the tests in a text file. Email your results and include any additional information you deem relevant to apl@assimilateinc.com. The APL Manager will review and publish your results.
• Should your test results be too close (usually within 10% or less) to APL's required performance minimums, based on our demo system's performance, ASSIMILLATE™ may require testing of your solution with SCRATCH itself. This can be done directly at the APL or at your company test lab. Please contact apl@assimilateinc.com to discuss the possible arrangements. If you pass this secondary testing stage, the APL Manager will publish your results, along with the backup information regarding the successful use of SCRATCH with your solution.

• The actual I/O transactions derived from the I/Ometer test do NOT directly correspond to the likely framerate that SCRATCH will provide under playback conditions. Please refer to the results page for an explanation on how to interpret the results of your tests.
• If you are an End User trying to test your existing storage for its suitability for use with SCRATCH we understand that in some situations using a completely empty array may not be feasible. In this case you can still use I/Ometer with the APL configuration file to get an indication of the suitability of your storage. To run the tests, we suggest that you fill up your storage array to no more than 80% full, and then let I/Ometer generate its "iobw.tst" file in the remaining free space. Don't forget to delete the "iobw.tst" file after the tests are completed to reclaim the free space. It's commonly found at the root level of your drive.