MQSim Simulator

MQSim is a simulator designed to capture the behavior of both modern multi-queue NVMe SSDs and conventional SATA-based SSDs. It models several critical features including:

• Modern multi-queue-based host–interface protocols (e.g., NVMe).
• Steady-state SSD behavior.
• End-to-end latency of I/O requests.

MQSim can be operated as a standalone tool or integrated into a full-system simulator.

MQSim workloads are defined in an XML file. If the specified file does not exist, MQSim will automatically create a sample file named workload.xml.

Workloads are organized into a hierarchy:

1. <MQSim_IO_Scenarios>: The root container for all workload definitions.
2. <IO_Scenario>: A set of workloads executed together. MQSim simulates each scenario separately by rebuilding the Host and SSD models and generating a unique output file (e.g., workload_scenario_1.xml).
3. Workloads: Within an <IO_Scenario>, you can define up to 8 individual workloads. These can be either trace-based (using real system data) or synthetic (generated by MQSim).

Example structure:

<MQSim_IO_Scenarios>
	<IO_Scenario>
		<!-- Up to 8 workloads here -->
	</IO_Scenario>
	<IO_Scenario>
		<!-- Up to 8 workloads here -->
	</IO_Scenario>
</MQSim_IO_Scenarios>

To use MQSim on a Linux environment, compile the project using make and then execute the binary by providing the SSD configuration file and the workload definition file using the -i and -w flags respectively.

$ make
$ ./MQSim -i <SSD Configuration File> -w <Workload Definition File>

MQSim uses XML files to define the simulation environment, including the Host, SSD Device, and NAND Flash configurations.

Tip: If you provide a path to an XML file via the command line that does not exist, MQSim will automatically generate a sample XML file at that path for you to use as a template.

# Example command line usage (implied)
# mqsim <path_to_config.xml> ...

To study how the QueueFetchSize parameter affects performance, you must test two different SSD configurations across three workload scenarios each.

Configurations:

• For QueueFetchSize = 16: Use ssdconfig-queue-fetch-size=16.xml.
• For QueueFetchSize = 1024: Use ssdconfig-queue-fetch-size=1024.xml.

Workload Scenarios (run for each configuration):

1. Flow-1 alone: Use workload-queue-fetch-size-flow-1.xml.
2. Flow-2 alone: Use workload-queue-fetch-size-flow-2.xml.
3. Concurrent execution: Use workload-queue-fetch-size-flow-1-flow-2.xml.

Calculating Slowdown: Divide the response time from the concurrent execution by the respective baseline response time:

• Slowdown(flow-1) = ResponseTime(concurrent_flow-1) / ResponseTime(flow-1_alone)
• Slowdown(flow-2) = ResponseTime(concurrent_flow-2) / ResponseTime(flow-2_alone)

To use MQSim on Windows, follow these steps:

1. Open MQSim.sln in MS Visual Studio 2017 or a later version.
2. Change the Solution Configuration from Debug to Release.
3. Compile the solution.
4. Execute the resulting MQSim.exe via the command line or the Visual Studio run button. When running via command line, you must specify the paths to the SSD configuration file and the workload definition file using the -i and -w flags.

$ MQSim.exe -i <SSD Configuration File> -w <Workload Definition File>

To study the contention effect in the SSD back end, use the configuration file ssdconfig-backend-contention.xml. You must run three separate experiments using the following workload files:

1. Flow-1 alone: Use workload-backend-contention-flow-1.xml to get the baseline response time for flow-1.
2. Flow-2 alone: Use workload-backend-contention-flow-2.xml to get the baseline response time for flow-2.
3. Concurrent execution: Use workload-backend-contention-flow-1-flow-2.xml to get the response times for both flows running simultaneously.

Calculating Slowdown: Divide the response time from the concurrent execution by the respective baseline response time:

• Slowdown(flow-1) = ResponseTime(concurrent_flow-1) / ResponseTime(flow-1_alone)
• Slowdown(flow-2) = ResponseTime(concurrent_flow-2) / ResponseTime(flow-2_alone)

To study the contention effect on the write cache, use the configuration file ssdconfig-datacache-contention.xml. You must run three separate experiments using the following workload files:

1. Flow-1 alone: Use workload-datacache-contention-flow-1.xml to get the baseline response time for flow-1.
2. Flow-2 alone: Use workload-datacache-contention-flow-2.xml to get the baseline response time for flow-2.
3. Concurrent execution: Use workload-datacache-contention-flow-1-flow-2.xml to get the response times for both flows running simultaneously.

Calculating Slowdown: Divide the response time from the concurrent execution by the respective baseline response time:

• Slowdown(flow-1) = ResponseTime(concurrent_flow-1) / ResponseTime(flow-1_alone)
• Slowdown(flow-2) = ResponseTime(concurrent_flow-2) / ResponseTime(flow-2_alone)

The fast18 folder contains input files required to replicate the experiments presented in the FAST 2018 paper. The experiments are categorized into three main studies: Contention Effect on the write cache, Contention Effect in the SSD Back END, and the effect of the QueueFetchSize parameter.

To perform these experiments, you must run MQSim multiple times using specific combinations of SSD configuration files (.xml) and workload definition files (.xml).

The Block_Pool_Slot_Type class represents the metadata for a single physical block. Key fields include:

• BlockID: The unique identifier for the flash block.
• Current_page_write_index: The index of the next page to be written.
• Current_status: The current Block_Service_Status.
• Invalid_page_count: Number of invalid pages in the block.
• Erase_count: Number of times the block has been erased.
• Invalid_page_bitmap: A bit sequence where 0 is valid and 1 is invalid.
• Hot_block: Boolean flag used for hot/cold data separation to reduce write amplification.
• Ongoing_user_read_count / Ongoing_user_program_count: Counters for active user operations on the block.