# High-Performance Garbage Collection Scheme with Low Data Transfer Overhead for NoC-Based SSDC
## 4 Evaluation
### Experimental Results  
We conducted simulations using our C model of the SSD, along with trace files extracted from various workloads. To evaluate the effectiveness of the proposed GC scheme, we measured the read and write latency of the SSD for each workload. While we acknowledge that most commercial SSDCs now use interconnects, to the best of our knowledge, no academic research has yet addressed this approach. Therefore, we compared the performance of our proposed method with a conventional approach that uses an unconditional copy-back scheme, as explained in this paper. Table 4 summarizes the average latency for both the conventional GC scheme, which unconditionally copies back ECC results, and our proposed scheme, which replaces this process with a local copy-back. As shown in Table 4, the proposed GC scheme improved average latency by up to 26.9%, demonstrating the effectiveness of the proposed scheme. It is important to note that the MySQL, Dbench, and SQLite workloads do not include any read operations, so corresponding measurement data are not available. As shown in Table 4, the average write latency improvements vary across workloads, with Cassandra showing the most significant improvement, followed by Dbench, MySQL, SQLite, MongoDB, and RocksDB. To understand the reasons behind these differences, we analyzed the host request patterns for each workload, as illustrated in Figure 6. Cassandra, Dbench, MySQL, and RocksDB workloads display highly dynamic request patterns, and SQLite and MongoDB workloads show relatively static host request patterns. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline Avg. Read Latency (ms) & Cassandra & Dbench & MySQL & SQLite & MongoDB & RocksDB \\ \hline Conventional & 1.729 & - & - & - & 0.826 & 0.856 \\ Proposed & 1.712 & - & - & - & 0.824 & 0.855 \\ \hline Avg. Write Latency (ms) & Cassandra & Dbench & MySQL & SQLite & MongoDB & RocksDB \\ \hline Conventional & 20.714 & 8.981 & 1.159 & 1.151 & 1.118 & 1.467 \\ Proposed & 15.137 & 6.811 & 1.076 & 1.097 & 1.067 & 1.461 \\ \hline Proposed/Conventional & Cassandra & Dbench & MySQL & SQLite & MongoDB & RocksDB \\ Improvement Ratio (\%) & \multirow{2}{*}{0.983} & \multirow{2}{*}{-} & \multirow{2}{*}{-} & \multirow{2}{*}{-} & \multirow{2}{*}{0.242} & \multirow{2}{*}{0.117} \\ Avg. Read latency & & & & & & \\ Avg. Write latency & & & & & & \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Average latency of read/write requests. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Workloads** & **Cassandra** & **Dbench** & **MySQL** & **SQLite** & **MongoDB** & **RocksDB** \\ \hline Read Ratio (\%) & 80.2 & 0.0 & 0.0 & 0.0 & 36.9 & 50.5 \\ Write Ratio (\%) & 19.8 & 100.0 & 100.0 & 100.0 & 63.1 & 49.5 \\ Seq. Request (\%) & 56.8 & 13.2 & 9.8 & 18.7 & 18.7 & 9.9 \\ Rand. Request (\%) & 43.2 & 86.8 & 90.2 & 81.3 & 81.3 & 90.1 \\ Aver. Read Size (KB) & 70.5 & 4.0 & 0.0 & 4.0 & 6.4 & 4.9 \\ Aver. Write Size (KB) & 103.7 & 7.6 & 5.8 & 4.9 & 4.7 & 4.5 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Characteristics of trace files. Figure 6: _Cont._  
To gain deeper insights, we measured several key metrics: the number of read/write requests from the host, the number of pending requests, and the number of requests generated by the GC process. Figure 7 presents the results across all workloads. Cassandra exhibits a highly dynamic pattern of read/write requests, with occasional spikes that lead to a significant increase in pending requests. In contrast, MongoDB follows a more periodic pattern, where moderate request volumes are generated over a period, followed by intervals of inactivity. This cycle repeats regularly. Because the request load in MongoDB remains well within the SSDC's capacity, the number of pending requests remains minimal. In other words, read/write requests from the host are promptly serviced as they are queued in the task queues when using MongoDB.