# High-Performance Garbage Collection Scheme with Low Data Transfer Overhead for NoC-Based SSDC
## 4 Evaluation
### Experimental Results
The proposed scheme effectively reduces the GC load and has a more pronounced impact on improving SSD latency, particularly when the host request pattern is more dynamic. Interestingly, the proposed GC method does not lead to significant improvements in latency for RocksDB benchmark, which shows occasional surges of host requests. This is because the number of copy-back operations in RocksDB is notably lower compared to the other benchmarks as shown in Figure 8. In RocksDB's case, journal data occupy almost 70% of the entire data. Journal data refer to the log information used by Linux file systems to ensure data integrity and recoverability in the event of a system crash or power failure. The total amount of journal data is fixed, and old journal data are periodically overwritten by new journal data. Therefore, GC target page that stores journal data only needs erase operation without copy-back operation. This is why RockDB has a very low copy-back count and the proposed scheme does not show significant improvement. Figure 6: Host request patterns. Figure 7: _Cont._  
However, a higher copy-back count does not always correspond to a greater performance improvement. For example, SQLite exhibits a significantly higher copy-back count than MySQL, yet their improvement rates are similar. As shown in Figure 7d, SQLite experiences minimal pending requests due to GC, meaning that host requests are typically processed immediately. As a result, the proposed GC scheme has a relatively small impact on SQLite's performance, which is reflected in the lower improvement rate shown in Table 4. In contrast, Figure 7c illustrates that MySQL frequently experiences pending requests due to GC, with a higher volume of such requests. Consequently, the latency improvements from our algorithm are more pronounced, as they apply to host requests that are delayed by GC. This explains why MySQL, despite having fewer copy-backs, achieves a performance improvement similar to SQLite's. Figure 8: Number of copy-backs. Figure 7: Number of host requests, GC requests, and pending requests. An interesting observation regarding the Cassandra workload is that the performance improvement is significantly more pronounced for write requests. To investigate this further, Figure 9 presents a graph that separates Cassandra's read and write requests. While read requests follow a relatively monotonic pattern, write requests are highly irregular, with sudden surges in volume. This suggests that the accumulation of pending requests in Cassandra, as observed earlier, is primarily driven by these sharp increases in write requests, while read requests remain stable and do not exhibit similar fluctuations. Table 5 compares the peak latency of the conventional GC scheme with that of the proposed GC scheme. As shown, the proposed scheme reduces peak latency by up to 50.0%. Similar to the pattern observed for average latency, the improvement in maximum latency correlates with the irregularity of host request patterns. When listing the workloads by the extent of improvement, the order is as follows: Cassandra, Dbench, MySQL, SQLite, MongoDB, and RocksDB. Excluding RocksDB, which has an exceptionally low copy-back count, this suggests that greater irregularity in host request patterns leads to a more significant improvement in peak latency. To account for operation uncertainties in our experimental results, we conducted a total of five trials for our algorithm, calculating the standard deviation for the experimental results of each workload. As shown in Table 6, the standard deviation for average latency is nearly zero. In contrast, there is a tendency for a larger standard deviation in maximum latency.