# Adapting the GACT-X Aligner to Accelerate Minimap2 in an FPGA Cloud Instance
## 4 Discussion
### The Transfer Channel Issue  
The discussion in the previous section indicates a possible performance limitation due to the competition for the PCIe transfer channel. In [32], the authors have shown that the experiments made on communication-intensive applications (i.e., spam filtering and face detection) presented a maximum of 2\(\times\) acceleration performed on single board instances of different cloud service providers. Their results corroborate with the results shown in Sections 2.5 and 3.3. A maximum speed-up of 1.91\(\times\) during the extending step corresponds to a maximum speed-up of 1.41\(\times\) in the integrated system, considering the time profile of Minimap2. This paper makes clear the influence of the PCIe transfer channel on the overall system's performance. In order to verify the behavior of GACT-X with respect to the data transfer, a second run of experiments was made. Time measurements were taken for every kernel processing, data transfer, and waiting-in-line instance and were accumulated, respectively. These instances in each thread were measured independently of any other part of Minimap2'sexecution that could occur concurrently. Therefore, the total accumulated time cannot be directly correlated to the total execution time, shown in Table 6, except for the case of a single thread, which is completely sequential. The kernel processing times were measured using the function \"clGetEventProfilingInfo\" and START and END event flags. The data transfer times, which include the times to transfer sequences and tile information, as can be seen by items 1 and 2, respectively, in Figure 6, are measured similarly. The time spent by the threads waiting in line for a kernel was measured using \"clock_t\". Each writing, reading, and kernel event had to be completed for the execution of the code to proceed to the next line by setting an OpenCL blocking resource so that the measurements could be taken. The results are displayed in Table 7. The datasets listed in column 1 are separated into one- or two-kernel cases in column 2. Column 3 divides into rows the times measured in seconds for processing, data transfer, and waiting in line. All eight threads cases are treated in the remaining columns. Considering that the kernel processing time reflects the computation of the total amount of the inputs, which is constant throughout the different kernel and thread configurations, most of the results were consistent. Considerate inconsistency was observed on configurations of six or more threads. Since the OpenCL's clEnqueueTask command is a macro, the management of large numbers of threads probably starts to affect the measurements of its time span. For all datasets, the data transfer time increased with the number of threads (for a fixed implementation) and with the number of kernels (for a fixed number of threads). This reinforces the suspicion about a single-channel conflict of the data transfer. With respect to the time in line, for all datasets, in the single thread cases that have a sequential nature, there will always be a kernel available, and the observed waiting time is close to zero. In the case of two threads, for a two-kernel implementation, the same occurs. However, for a one-kernel implementation, a second thread has to wait for the kernel to be liberated from the computation of a first thread; therefore, the waiting time in line is larger, for example, 83.11 seconds for the simulated PacBio dataset. Another observation regarding the time in line is that, for all datasets and implementations, it increases with the number of threads.