What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Slow rclone transfers are usually diagnosed, not guessed. First determine whether the delay is a bandwidth cap, remote-service response, transfer concurrency, local disk I/O, or mount/VFS behavior. Record the exact command and workload, verify that no limit is configured, measure the remote path when safe, expose rclone’s statistics, and change one setting at a time. The right fix depends on which stage is actually slow.
Start by identifying what “slow” means
A copy that spends most of its time listing files has a different problem from one that moves data at a low sustained rate. A mounted remote that pauses while an application reads a large file has different constraints from a direct rclone copy. Before changing flags, classify the symptom.
| Observed symptom | Most relevant stage to investigate | Useful first check |
|---|---|---|
| Files take a long time to appear, compare, or decide whether they need copying | Directory listing, metadata checks, or checker concurrency | Watch statistics during the checking phase; compare a run with an appropriate checker count |
| Transfer rate is consistently close to a round number and never rises | Configured bandwidth limiter | Inspect --bwlimit and any wrapper, profile, or environment default |
| Several transfers start, then the remote times out or stalls | Remote responsiveness or excessive concurrency | Repeat with fewer transfers and checkers |
| Remote tests are fast but the destination disk cannot keep up | Local read or write I/O | Observe disk utilization and test with a workload that avoids simultaneous checking |
| Direct copies are acceptable but applications reading a mount pause | VFS read-ahead, chunking, cache, or high-latency behavior | Use mount-specific VFS guidance rather than assuming copy flags apply |
Record the conditions for every comparison: the full command, upload or download direction, source and destination types, approximate file sizes, file count, and whether the operation is a copy, sync, or mount workload. Compare runs only when those conditions are similar. A single large file and thousands of small files exercise very different parts of a backend.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsCheck for an explicit bandwidth cap
Rclone’s --bwlimit limiter is measured in bytes per second, not bits per second. It can apply different limits to uploads and downloads, and its default is no bandwidth limit. A value that looks like “100” therefore means 100 bytes per second unless a unit suffix is supplied; it does not mean 100 megabits per second.
#1 Best Overall
- Easily store and access 2TB to content on the go with the Seagate Portable Drive, a USB external hard drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
- Inspect the command and its source. Look for
--bwlimitin the command line, scripts, aliases, scheduled jobs, container definitions, and profiles. Also check environment or wrapper defaults that add rclone options automatically. - Use consistent units. Rclone can display rates in bits with
--stats-unit bits, while transferred volume remains in bytes. Do not compare a bits-per-second display directly with a bytes-per-second limiter without converting. - Run a controlled test. Remove the cap only when your network and service policy permit it, then compare the same files and direction. If the rate rises immediately to the expected path capacity, the limiter—not the backend—is the bottleneck.
rclone copy /source remote:path --stats 15s --log-level INFO
rclone copy /source remote:path --bwlimit 10M --stats 15s --log-level INFO
The second command is an example of a 10-megabyte-per-second cap, not a recommendation. Keep a deliberate limit if it protects other users or prevents a service from throttling you; the diagnostic question is whether the configured ceiling explains the observed rate.
Measure the remote path with rclone test speed
When creating temporary data is acceptable, rclone test speed remote: provides a backend-focused comparison. It runs a series of uploads and downloads using varying file sizes and file counts, reports each test’s speed, and creates then removes test files in a randomly named remote directory.
rclone test speed remote:What the test can tell you
- If both upload and download tests are slow, the backend path, service throttling, network route, or local system may be limiting the operation.
- If uploads are slow but downloads are substantially faster, investigate write-side service limits, upload request behavior, or local source reads.
- If large-file tests are reasonable but small-file tests are poor, request overhead, metadata operations, or file-count effects are dominating.
Important limits of the result
The test is not a guarantee of the speed of your real job. Its workload may not match your file sizes, count, encryption, filters, or local disk. Documentation warns that small file caps and large files can make the test duration inaccurate. The command was added in rclone 1.72; if your installed version does not recognize it, check that version’s built-in help before assuming the remote lacks support.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Use a remote where temporary creation and deletion are allowed. The test removes its files after a clean exit, so do not run it in a location where test objects would be disruptive or incur unexpected charges.
Rank #2
- Easily store and access 5TB of content on the go with the Seagate portable drive, a USB external hard Drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
Make transfer statistics visible and interpretable
Rclone’s periodic statistics show whether data movement is active, how much has transferred, and the current rate. The documented default interval is one minute. Statistics are logged at INFO by default, while rclone’s default NOTICE level does not display them; request an interval and a visible log level explicitly.
rclone copy /source remote:path
--stats 15s
--log-level INFO
rclone copy remote:path /destination
--stats 15s
--stats-unit bits
--log-level INFO
Read the phases separately
- Checking or listing: little or no byte volume moves while rclone compares metadata. Long pauses here point toward backend response time, file count, or checker concurrency.
- Transferring: active byte counts and transfer rates reveal whether the bottleneck appears during reads, writes, or remote requests.
- Retries and errors: repeated retries can make an average rate look low even when individual requests are fast. Record the errors and timestamps rather than tuning blindly.
Take a baseline for one representative run. After each change, keep the same statistics interval, files, direction, and destination, then compare elapsed time, sustained rate, retries, and completion behavior.
Adjust transfers and checkers one variable at a time
The documented starting defaults are four parallel file transfers (--transfers 4) and eight checkers (--checkers 8). These are starting points, not performance guarantees.
| Setting | What it controls | When increasing may help | When reducing may help | Trade-off |
|---|---|---|---|---|
--transfers |
Concurrent file data transfers | Bandwidth is available and individual files do not saturate the path | The remote times out, rate limits, or becomes unstable under parallel writes | More request pressure, local memory and I/O contention |
--checkers |
Concurrent file checking and metadata work | Listing/checking is the measured slow phase and the backend handles concurrent requests | The backend responds slowly, returns throttling, or times out during checks | More API pressure; checks can compete with data reads and writes |
--max-connections |
Concurrent backend API calls, subject to backend implementation | Only when documentation and measurements show a connection ceiling is relevant | When deadlocks, starvation, or unexplained stalls appear after changing it | It is not a universal speed control and may interact with transfers and checkers |
A safe experiment
- Run the baseline with the defaults and visible statistics.
- Change only
--transfers, for example from 4 to 2 or 8, while keeping everything else identical. - Repeat the same run, recording completion time, rate, retries, and whether the remote remains responsive.
- Restore the better value, then test
--checkersseparately. For a slow-reacting backend, rclone’s documentation specifically suggests trying four or fewer checkers.
More concurrency can increase throughput when the path is under-filled, but it can also turn a marginal backend into a timeout and retry loop. A lower instantaneous rate that completes reliably can be faster overall than a bursty run that repeatedly retries.
Rank #3
- Easily store and access 1TB to content on the go with the Seagate Portable Drive, a USB external hard drive.Specific uses: Personal
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop. Reformatting may be required for Mac
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
Separate checking from data movement when local I/O is constrained
Checking metadata while reading source files and writing destination files can make a disk seek between competing workloads. Rclone documents --check-first for I/O-limited systems: it completes the checking phase before starting transfers.
rclone copy /source remote:path
--check-first
--stats 15s
--log-level INFO
What to expect
- The first phase may appear slow because it is doing checks without moving much data.
- The option can require more memory because rclone retains the work backlog before transfers begin.
- It helps only when checking and transfer I/O are interfering. It cannot make a slow remote service or a capped network faster.
If measured local write speed is the limiting stage, the documentation identifies --multi-thread-write-buffer-size as an option to experiment with. Treat it as a workload-specific test: changing buffering can affect memory use and does not prove that replacing a disk is necessary.
Investigate local disk reads and writes
A remote speed test can be misleading when the real job reads from a busy source disk or writes to a destination that cannot sustain the incoming rate. Observe the local system while rclone runs:
- Compare a run from the actual source with a run from a known-fast local source, if available.
- Compare a real destination with a test destination whose write performance is established.
- Look for high disk utilization, queueing, filesystem contention, or a source that is also being scanned by another process.
- Separate checking and transfer phases with
--check-firstwhen simultaneous I/O is the measured problem.
Do not infer a hardware purchase from a low transfer rate alone. Establish that the disk is saturated, confirm that the remote path and limiter are not slower, and measure the same file workload before and after any change.
Rank #4
- 【Versatile Storage Expansion – For Gaming, Work & Everyday Use】 Running out of space on your PS5 or Xbox Series X/S? This external hard drive lets you store and play PS4 / Xbox One games directly, instantly freeing up your console’s internal storage for next‑gen titles. At the same time, it handles work file backups, media libraries, and cross‑device data transfers with ease. One drive, all your needs. *（Note: PS5 / Xbox Series X|S games cannot be run or stored directly from the external hard drive. However, by offloading your PS4 / Xbox One games, you can free up valuable space for newer titles.）*
- 【Patented Silicone Sleeve – Data Protection You Can Count On】 Worried about drops? We’ve got you covered. The patented built‑in silicone sleeve acts like a shock‑absorbing armor, cushioning your drive against bumps and falls. Whether it’s important work documents, precious family photos, or hard‑earned game saves, your data deserves this level of protection.
- 【Plug & Play, Compatible with Computers & Consoles】 No complicated setup—just plug in and go. Works seamlessly with Windows, Mac, and Linux computers, as well as PS4, PS5, Xbox One, and Xbox Series X/S. Process files at the office, back up data at home, or enjoy gaming in your downtime—one drive handles all your devices, simply and hassle‑free.
- 【USB 3.0 Ultra‑Fast Transfer – No More Waiting】 Tired of watching progress bars crawl? With USB 3.0 speeds up to 5Gbps, large files transfer in seconds. Whether you’re moving work documents, transferring hundreds of gigs of games, or backing up a year’s worth of photos, you get more done in less time.
- 【Sleek, Lightweight, and Ready to Go】 Weighing just 0.16 kg—lighter than a can of soda—this compact drive features a stylish mirror‑and‑frosted finish. Toss it in your bag and go, whether you’re heading to the office, visiting a friend for a gaming session, or giving a presentation on the road.
Use mount and VFS-specific diagnostics
A mounted remote is not equivalent to a direct copy. Applications often issue small, random, or sequential reads through the VFS layer, and high-latency object stores may need read-ahead to avoid waiting for every chunk.
Read chunk streams
Rclone’s mount documentation discusses read chunk streams and chunk size for high-performance object stores and high-latency links. The relevant VFS options include --vfs-read-chunk-size and its growth limit. Larger or growing chunks can reduce request overhead for sequential reads, but they can waste bandwidth for small or random reads and increase memory use.
Diagnose the workload, not just the mount
- Test the same object with a direct copy and through the mount. A large difference points toward VFS behavior or application access patterns.
- Measure sequential and random reads separately; an option that helps video playback may hurt a database-like workload.
- Do not assume copy/sync flags such as checker or transfer counts solve mount read latency. Use the mount page’s VFS guidance and change one read setting at a time.
Be cautious with --max-connections
--max-connections limits concurrent backend API calls, but it does not necessarily correspond one-for-one with physical network connections. Its effect depends on the backend and how transfers and checkers share calls.
It is therefore not a generic “make it faster” switch. Rclone’s documentation warns that an unsuitable value can cause deadlocks and explains its relationship with transfer and checker concurrency. Change it only when you have a specific connection-related symptom, keep the change isolated, and stop if requests stop making progress.
Best Value
- High capacity in a small enclosure – The small, lightweight design offers up to 6TB* capacity, making WD Elements portable hard drives the ideal companion for consumers on the go.
- Plug-and-play expandability
- Vast capacities up to 6TB[1] to store your photos, videos, music, important documents and more
- SuperSpeed USB 3.2 Gen 1 (5Gbps)
A complete bottleneck-finding procedure
- Capture the workload. Write down the exact command, direction, remote type, source and destination, file-size distribution, file count, and whether the operation is copy, sync, or mount.
- Expose statistics. Add
--stats 15s --log-level INFO; use--stats-unit bitsonly when a bits-per-second display makes comparison easier. - Check for limits. Inspect
--bwlimit, scripts, aliases, profiles, and environment defaults. Confirm whether upload and download limits differ. - Identify the slow phase. Decide whether time is spent listing/checking, transferring, retrying, reading locally, writing locally, or serving mount reads.
- Measure the backend independently. If temporary objects are acceptable and the installed version supports it, run
rclone test speed remote:. Compare upload and download results and note file-size effects. - Test concurrency. Keep the default four transfers and eight checkers as the baseline. Change one value, then repeat the same workload. For slow-reacting services, try fewer checkers rather than immediately adding transfers.
- Test local I/O. Watch source and destination disk behavior. If checking competes with data movement, try
--check-firstand account for its additional memory requirement. - Handle mounts separately. For VFS workloads, evaluate read chunking and latency with mount-specific options instead of applying direct-copy assumptions.
- Record the winner. Keep the setting that improves completed-job time and reliability, not merely the highest short-lived rate. Revert changes that increase retries, timeouts, memory pressure, or API errors.
Common mistakes that hide the real cause
Comparing unlike runs
Comparing a single 20-GB file with a directory of 100,000 small files does not isolate a setting. File count changes metadata work, request count, and concurrency behavior. Keep test data and direction consistent.
Reading the wrong units
A statistics display in bits and a limiter expressed in bytes can differ by a factor of eight before any network behavior is considered. Keep the unit visible in notes and convert explicitly.
Increasing every concurrency flag at once
If transfers, checkers, and maximum connections all change together, you cannot tell which one helped or caused timeouts. Controlled, one-variable experiments take longer but produce a defensible result.
Treating defaults as promises
Four transfers and eight checkers are documented defaults, not measured throughput targets. A backend may perform best below or above them depending on latency, service limits, file sizes, and request behavior.
Assuming a mount is a copy
Applications reading through VFS may need different chunking and caching behavior from a batch copy. Diagnose the application’s access pattern and use mount-specific settings.
How to interpret the final diagnosis
| Evidence after controlled tests | Most defensible conclusion | Next action |
|---|---|---|
| Removing a configured cap raises the rate immediately | The limiter was the active ceiling | Choose a policy-compliant limit that leaves capacity for other traffic |
rclone test speed and the real job are both slow in the same direction |
The backend path or service behavior is likely limiting that direction | Compare file-size patterns, concurrency, and service-side limits |
| Fewer checkers stop timeouts during listing | Checker pressure or slow backend response was contributing | Keep the lower checker count and verify completion time on a repeat run |
| More transfers improve a stable run without retries | The previous workload under-filled available capacity | Retain the measured value and monitor memory, API pressure, and reliability |
| Remote tests are healthy but local disk utilization is saturated | Local I/O is the bottleneck | Reduce contention, separate checking, or test buffering options |
| Only mounted reads are slow | VFS access pattern, chunking, or latency is implicated | Tune mount read behavior and test with the real application workload |
Rclone’s documentation can tell you what a flag does and what defaults it uses; it cannot identify your root cause without your backend, command, hardware, logs, and measurements. A short baseline-and-one-change experiment is more reliable than copying a “fast” configuration from an unrelated remote.
