High-Speed
Exacoola transfers larger files and numbers of files faster than ever before.
Want to know how long your file transfer will take? Check it out now on Exacoola.
If the transfer preparation takes too long, the overall file transfer time will also be significantly slower.
| Classification | Preparation procedure | Limitations |
|---|---|---|
| Built-in SSD/HDD | 1) Connect and secure the SATA/NVMe cable 2) Recognize the device in the BIOS 3) Check the device in Disk Management after booting the OS 4) Create and initialize a partition (select MBR/GPT) 5) Create/format a file system (NTFS/EXT4, etc.) 6) Set up the mount and assign a drive letter | - Windows cannot read EXT files - macOS cannot write to NTFS - Server security policies restrict hot-swap. |
| FTP Transfer (Client to Server) | 1) Install an FTP server 2) Create an account and set home directory permissions 3) Open FTP port (21) on the firewall 4) Open a passive mode port range (at least 500-2000) 5) Forward ports on your router/security device 6) Test connection (account login/list verification) 7) Test a large file to verify resume 8) Install a client-side FTP tool | - Default FTP is insecure and prohibited by many security policies. - Passive Mode does not work properly in NAT environments (port range issues). - Server functionality is limited in Windows Home Edition. - The default FTP server has been removed in the latest version of macOS (separate installation required). |
Exacoola reduces preparation time to less than a minute without complicated setup.
And the actual transfer completion time always takes longer than expected.
| Miscalculation cases | Factors to consider | Consequential error point |
|---|---|---|
| Judging overall speed based on initial speeds of USB, SSD, and HDD | Average transfer speed, file size/number, I/O bottleneck | Misconception that the initial speed will be maintained |
| Judging overall speed based on initial FTP speed | Network congestion, packet loss, long transfer times | Misconception that the initial speed will be maintained |
| Shortening overall time by compressing and transferring | Compression/decompression time, CPU usage, number of files | Excludes the time for compression and decompression |
| Judging transfer completion after excluding integrity verification | Checksum calculation, retransfer probability | Assuming transfers are ready to use immediately |
| Overestimating initial speed due to network device cache | Device buffer, network bandwidth, I/O performance | Assuming the network maintains its initial speed |
| Confused with the speed of a single large file transfer and the speed of multiple small files | Number of files, file open/close overhead, I/O efficiency | Overestimating small file transfer speeds |
| Judging based solely on instantaneous speed graphs of transfer software | Average transfer speed, network variability | Overestimating overall performance based on instantaneous transfer speeds |
| Ignoring intermediate network interruptions and retransfer times | Packet loss, retransfer time, network stability | Assuming there are no interruptions or errors during transfer |
| Ignoring encryption/security protocol overhead | Encryption/decryption CPU load, protocol overhead | Mistaking that transfers are the same as the maximum device/network speed |
| Illusion of linear speed improvement during multi-threaded/simultaneous transfers | Network bandwidth, I/O contention, CPU load | Mistaking that simultaneous transfers are n times faster, which can actually reduce speed |
Exacoola calculates the expected transfer time in advance, allowing you to check the exact completion time.
Network and hardware performance also significantly impact transfer speeds.
| Factors | Reasons |
|---|---|
| Bandwidth | The maximum transfer and reception capacity provided by a line. If bandwidth is low, the line itself becomes a bottleneck. |
| Network distance (latency, RTT) | Longer geographical distances increase round-trip delay (RTT), degrading TCP performance. This is a key bottleneck in high-speed file transfers. |
| Packet loss rate | High loss rates lead to increased retransfers, which in turn leads to a sharp decrease in overall speed. This is common in international, LTE, and Wi-Fi environments. |
| Network congestion/shared line usage | Simultaneous use of the same line by multiple devices reduces transfer speeds. |
| NAT/firewall configuration | The presence of more packet inspection and security devices increases latency and reduces transfer speeds. |
| Wireless environment characteristics | Wi-Fi, 4G/LTE, and 5G experience significant transfer speed variations due to interference and quality variations. |
| CPU performance | The CPU is a bottleneck during encryption/compression/hash processing. |
| Memory capacity and buffer processing | Transfer speeds vary depending on how many file fragments can be loaded and processed in memory. |
| Disk I/O speed (HDD/SSD/eMMC) | SSDs are fast, while HDDs/eMMCs slow down significantly when there are many files. |
| File system type | The structure of file systems such as EXT4, NTFS, and FAT32 significantly impacts the processing of large numbers of small files. |
| File size (capacity) | Large files offer good single-stream efficiency, but are at greater risk of retransfer and I/O bottlenecks. |
| Number of files | Speed drops sharply for files with hundreds of thousands or millions due to the cost of reading metadata. |
| File fragmentation | Severe disk fragmentation slows read/write I/O speeds. |
| File creation frequency | The more real-time files generated, the higher the monitoring and queuing processing costs. |
| Number of concurrent transfers (parallelism) | The number of files transferred simultaneously is crucial - too many result in I/O and network saturation, while too few waste network resources. |
| Encryption applied | TLS/SSH connections increase CPU overhead, slowing down connections. |
| Compression method | While compression can reduce the amount of data transferred, it increases CPU processing time. |
| transfer retry/error handling method | Without intelligent retransfer (resume), the entire file is retransferred, resulting in significant delays. |
| Number of simultaneous receiving devices | When multiple devices send files to a server, the server can become a bottleneck. |
| RTT difference between servers/devices | If network quality varies between devices, the overall transfer schedule can be extended. |
| Routing path quality | Speeds vary significantly depending on the route, such as between ISPs or via international networks. |
| Power and environmental conditions | Unmanned devices can experience interruptions due to power instability. |
| I/O contention during device use | If the line is in production, transfers can be slowed due to device I/O priorities. |
| Time-of-day traffic changes | Speeds can be reduced if bandwidth is congested at certain times. |
| Security solutions (VPN, SSL inspection) | Delays and slowdowns occur due to encryption rechecks. |
However, in an in-house environment with high-performance equipment, transfers are often slow.
| Reason | Description |
|---|---|
| Large file transfers (tens of GB to several TB) | For single, large files, protocol overhead, I/O buffering delays, and disk write speeds can be bottlenecks. Faster network speeds alone don't necessarily translate into faster performance. In particular, server-side RAID, NAS, and storage throughput can become a bottleneck, limiting transfer speeds. |
| Transferring large files (hundreds of thousands) | With a large number of files, the cost of reading and writing metadata (opening and closing files) accumulates, slowing down transfer speeds exponentially. rysnc, scp, and Samba are all extremely vulnerable to handling large volumes of small files. |
| Sharing method (upload → download) structure | Methods that route data through a NAS/shared folder/FTP server rather than directly: - A two-stage transfer structure (upload → server → download). - Storage I/O is used twice. - Simultaneous access by multiple users results in performance fragmentation. This ultimately results in a structure that completely underutilizes network bandwidth and server performance. |
| A slow protocol based on sequential transfer | FTP, scp, rsync, and SMB transfer files sequentially. Parallel transfers are rare, and even at 10 Gbps networks, utilization remains at 10-40% due to the protocol's inherent characteristics. scp/rsync, in particular, suffers from CPU bottlenecks due to SSH encryption, further slowing down speeds. |
| Inconvenient tool (not suitable for automation/bulk transfers) | FTP clients, SAMBA, scp, rsync, etc. are: 1) Inconvenient for thousands of devices and tens to millions of files. 2) Difficult to retry in case of failure. 3) Many CLI tools lack a user interface. 4) Complex scripting is required for automation. This creates human overhead that prevents the use of high-performance environments. |
| Unable to utilize high-performance bandwidth | The most common reasons for 10Gbps network performance but only 200-400MB/s transfers are: 1) Single-connection protocols (FTP/scp/SAMBA). 2) Insufficient CPU capacity (SSH encryption, RAID parity calculation). 3) Lack of parallelism due to upload/download structure. 4) Network RTT (bandwidth delay - performance BDP unused). The device is high-performance, but the protocol is the bottleneck. |
| External transfer via messengers, etc. (capacity limit + 2 transfers) | Messenger files are sent outside the company and then re-entered, so there are two transfers: company → external service upload, external → company download. Additionally: file size limits exist, external network bandwidth is significantly lower than internal network bandwidth, and security policies can limit speeds. Even with 10 Gbps equipment, perceived speeds drop to tens to hundreds of Mbps. |
| Increased network RTT / distance issues | Even within a company, if RTT increases due to different floors, different buildings, or internal/external network connections, transfer speeds for SMB, scp, and rysnc decrease dramatically. SMB is particularly sensitive to RTT, and can drop to tens of MB/s even in a 10 Gbps environment. |
| Storage bottlenecks (NAS, SAN, RAID) | The network is fast, but if the disks on the NAS/server/PC are slow or in poor RAID state: - Write speed is the bottleneck - Read speed is the bottleneck - Insufficient cache → The network speed is lightning fast, but the speed is not achieved because the disks are slowly running out. |
| Single-threaded processing of servers/protocols | FTP/scp/rsync/Samba mostly operate on a single connection basis. Even if the server CPU is multi-core, the transfer itself is single-threaded, failing to leverage the multi-core performance of high-performance servers. |
| Rate limiting for corporate firewalls/security policies | In corporate networks with IPS/IDS, DLP, and SSL Inspection enabled, additional packet inspection limits bandwidth. Even with a basic 10 Gbps device, effective throughput can sometimes be as low as 1-2 Gbps. |
Exacoola maximizes transfer speeds by leveraging device performance and bandwidth.
Especially when transferring large files, you often experience severe slowdowns.
| File count (total size) | USB drive | Samba (NAS) | FTP | rsync (ssh) | scp (ssh) | Exacoola |
|---|---|---|---|---|---|---|
| 100,000 files (100GB) | 25 minutes | 15 minutes | 8 minutes | 20 minutes | 12 minutes | 2 minutes 5 seconds |
| 1,000,000 files (100GB) | 5 hours 30 minutes | 2 hours 30 minutes | 1 hour 20 minutes | 4 hours | 2 hours | 2 minutes 16 seconds |
| 2,000,000 files (100GB) | 12 hours | 5 hours 10 minutes | 2 hours 40 minutes | 8 hours 20 minutes | 4 hours 10 minutes | 2 minutes 25 seconds |
| 3,000,000 files (100GB) | 19 hours 10 minutes | 8 hours | 4 hours | 13 hours | 6 hours 20 minutes | 2 minutes 38 seconds |
| 4,000,000 files (100GB) | 26 hours 20 minutes | 10 hours 50 minutes | 5 hours 20 minutes | 17 hours 30 minutes | 8 hours 30 minutes | 2 minutes 42 seconds |
| 5,000,000 files (100GB) | 33 hours 20 minutes | 13 hours 40 minutes | 6 hours 40 minutes | 22 hours | 10 hours 40 minutes | 2 minutes 55 seconds |
Exacoola transfers large files at high speeds, regardless of the number or structure of files.
There are good reasons for slow speeds on long distances, such as overseas transfers.
| Classification | FTP | rsync | scp | Exacoola |
|---|---|---|---|---|
| 100GB single file | 6 hours - WAN RTT increases → TCP window limit, sequential transfer | 8 hours - WAN RTT + SSH encryption, initial checksum | 9 hours - SSH encryption + sequential transfer | 50 minutes - Minimizing WAN RTT impact, parallel split transfer, optimized TCP |
| 100GB single file | 8 days and 18 hours - Control channel repetition per file + RTT impact, many small files | 35 days - Checksum + metadata iteration per file, sequential processing | 700 hours (approximately 29 days) - Repeated connection initialization per file + encryption | 1 hour 15 minutes - Split file transfers in parallel, multi-threading, and optimal bandwidth utilization |
Exacoola optimizes packet flow and routes to transfer files at high speeds even over long distances.
Even if it appears as “Transfer complete," post-processing and verification may take additional time.
| Classification | FTP | rsync | scp | Exacoola |
|---|---|---|---|---|
| Integrity verification procedure | 1. Confirm transfer completion (log/completion message) 2. Calculate the source file checksum (SHA-256) 3. Calculate the target file checksum 4. Compare the two checksums | 1. Confirm transfer completion 2. Calculate the source file checksum 3. Calculate the target file checksum 4. Compare the two checksums (rsync option --checksum) 5. Generate a list of files with differences | 1. Confirm transfer completion 2. Calculate the source file checksum 3. Calculate the target file checksum 4. Compare the two checksums | None, included in the transfer time |
| Integrity verification time | 100GB single file: 20 minutes 1,000,000 files (100GB): 8 hours | 100GB single file: 20 minutes 1,000,000 files (100GB): 8 hours (including per-file checksum calculation) | 100GB single file: 20 minutes 1,000,000 files (100GB): 8 hours | None, included in the transfer time |
| Re-transfer | - In case of single file corruption: Full 100GB retransfer. - 100GB / 1,000,000 files: Only damaged/missing files are listed and retransferred. Retransfer time: 6 hours and 20 minutes for a single file, 2 hours and 10 minutes for large files (assuming 1% corruption) | - In case of single file corruption: Full retransfer - 1,000,000 files: Retransfer only corrupted/missing files (rsync automatically generates a list) Retransfer time: 8 hours and 20 minutes for a single file, 2 hours and 10 minutes for large files | - In case of single file corruption: Full retransfer - 1,000,000 files: Retransfer of only corrupted/missing files. Retransfer time: 9 hours and 20 minutes for a single file, 2 hours and 10 minutes for large files | None, included in the transfer time |
Exacoola optimizes every step from preparation to completion, significantly reducing overall transfer time.
| Classification | FTP | rsync | scp | Exacoola |
|---|---|---|---|---|
| Preparation time | Manual setup, accounts, port configuration required | Manual setup, SSH configuration required | Manual setup, SSH configuration required | Very short, under 1 minute |
| Initial setup complexity | High (security policies, ports) | Medium-high (various options) | Medium (SSH only) | Very low, simple UI-based setup |
| Transfer method | Sequential transfer | Sequential transfer | Sequential transfer | Parallel, multithreaded, fully optimized transfer |
| Transfer speed | Slow | Very slow | Very slow | Fast (optimized for long-distance transfer) |
| WAN stability | RTT increases → severe slowdown | RTT + encryption overhead → slowdown | SSH handshake overhead → slowdown | Minimized RTT impact, automatic packet recovery |
| Transfer verification (integrity) | Manual check required | Manual or option-based | Manual check required | Automatic integrity verification included |
| Corruption or missing files | Full retransfer required | Retransfer required | Retransfer required | Not needed - auto-detection & auto-retransfer |
| Large-scale multi-device deployment | Per-device repeated setup & checks | Per-device repeated setup & checks | Per-device repeated setup & checks | Independent of device count, automated parallel deployment |
| Burden of repeated transfers | Same procedures repeated | Same procedures repeated | Same procedures repeated | No repetition - automated scheduling |
| Operation during off-hours | Possible only during work hours | Possible only during work hours | Possible only during work hours | 24/7 automated operation (little to no manual work) |
| Handling massive file counts | Extremely slow | Very slow, heavy checksum overhead | Very slow | Parallel distributed processing, stable and fast |
| Recovery from failures | Manual diagnosis & retransfer | Log analysis required | Log analysis required | Automatic diagnosis, recovery, and retransfer |
| Security | Low (standard FTP is vulnerable) | Medium (SSH-based) | Medium (SSH-based) | Encrypted transfer with built-in integrity checks |
| Scalability | Low | Low | Low | High (supports hundreds to thousands of devices) |
| Total operational cost | High (requires manpower) | High (maintenance complexity) | High | Low (automation reduces operational labor by ~90%) |
| Overall assessment | Obsolete / inefficient | Hard to maintain | Unsuitable for long-distance transfer | Simplest, fastest, and most reliable |