📜 ⬆️ ⬇️

Java benchmarks: random patterns and regular results

Does mass storage device performance depend on the contents of the recorded files? At a time when the monopoly on the implementation of external memory computing systems belonged to magnetic disk drives, such a question would seem strange. Obviously, in such devices, the file transfer time is determined by its size, as well as fragmentation, forcing the device to perform additional positioning. And there is no reason for the dependence of speed on the content, if we talk only about hardware performance, without taking into account the software drivers that perform archiving or encryption of data at the file system level. And what about the issue with solid-state drives?

We tried to find the answer to this question by writing a java application using Non-Blocking I / O exchange technology. As a result, NIOBench appeared, with which you can get benchmarks of magnetic and solid-state media with various interfaces, and in fact, any external storage device (with the exception, perhaps, of devices with access discipline Read Only, but they also have their own plans).

During the development process, a number of situations arose when it was necessary to define testing scenarios. Let us leave working moments in the laboratory, let's dwell in detail on such an important aspect as the choice of the test pattern. There was no reason to use heuristic methods, as implemented, for example, in the AS SSD: in fact, this is a repetition of the past. It was decided to look for your option. Before moving on to his presentation, some tedious memories.
')

Zero and one factor


Modern non-volatile flash memory chips used in solid-state drives have their own built-in recording machine that optimally controls the programming process of the storage matrix. Inside such a chip is the main part of the logic of the programmer of a persistent storage device (ROM). This circumstance not only makes the electronic device compact, but also protects the manufacturer’s intellectual property, turning the chip into a “black box”.

Therefore, for clarity, consider the "antique" chips with electric programming, UV erasing and a volume of 2 kilobytes. Obviously, the devices of 30 years ago are significantly different from modern ones, however, a number of physical principles and effects have retained their relevance.


Fig. 1 . Chip interface contains address, data, control and power lines

As you know, after erasing such a chip, the memory cells are set to 0FFh or “all ones”. Bytes whose value should be 0FFh can simply not be written. In addition, the number and / or duration of the programming pulses required to write a byte depends on the ratio of the number of zeros and ones in this byte. Thus, there is a dependence of the recording time on the data. Note that if there are significantly more zeros in the recorded data than ones, the device developer may decide to store the data in an inverse form, saving not only the recording time, but also the chip life and even some (albeit microscopic) part of the power consumed.

Compression factor


A drive archiving information must inevitably use an algorithm that analyzes and converts data streams running between the host interface and the flash memory matrix.

This means that the processing time will be different, depending on the entropy , if, of course, the device developer does not deliberately eliminate this effect.

NIOBench test


In version v0.42, the NIOBench benchmark implements a script for filling test patterns (copied files) with pseudo-random data. By default, zeros are used as placeholders.

Two types of random number generators are supported:


If the RDRAND instruction is not supported, or there is no native library for this OS, the Hardware RNG option is not activated - benchmarks can be performed in the filling mode with zeros or programmatically generating a test pattern with pseudo-random numbers. The Data option selects one of three test methods:

  1. Zeroes - filling test files with zeros
  2. Software RNG (Random Number Generator) - filling test files with pseudo-random data, obtained programmatically, with methods of the java.util.Random class
  3. Hardware RNG - filling test files with pseudo-random data obtained by hardware using machine instructions RDRAND

Modes 1 and 2 are supported on all platforms. Mode 3 is supported if the processor supports the RDRAND instruction and the presence of a native library for the OS. This version contains native libraries for Windows 32/64. Support for RDRAND instructions is also planned for Linux.

Native libraries are packaged as part of a running JAR archive. Connection to the java application, procedures written in assembler, is based on the JNI ( Java Native Interface ) specification.

About the results


During test operations, the table at the top of the NIOBench utility window is populated with the results. The columns are separated statistics benchmarks: average, minimum and maximum speeds. The medians of reading, writing, and copying are displayed line by line, and then the average values ​​obtained in the process of performing the same operations.

The user can save the text report of the execution of benchmarks. It details the results for each of the iterations specified in the Count field. The data involved in the calculations of the medians are marked with the letter " M ".

When developing a test script, the task was to measure solely the performance of the drive (or data archiving schemes operating at levels below the file API, which is possible in some data storage systems) and its dependence on data. It is necessary to eliminate the dependence of the results on the performance of the random number generator itself. Therefore, test data arrays are filled once at the start of the application, and not during the execution of the measurement operation. Depending on the state of the Data option, which selects the test method, one of three prearranged arrays is used (zeros, soft-RNG, hard-RNG). Test data is repeated with a period of 1 megabyte.

Technology development and debugging


Writing and debugging java-applications are made in NetBeans 8.1 environment. Assembler libraries were written in FASM Editor 2.0, translated using Flat Assembler 1.71.49. Debugging 32-bit assembly code is performed in OllyDbg v2.01. Debugging of 64-bit assembly code is performed in FDBG v0025.

Source: https://habr.com/ru/post/308754/


All Articles