Download Performance

Open Settings → Downloads → Performance to choose a profile. Connection counts are limits: a file can use fewer connections depending on its size and the server.

Download speed can drop noticeably near completion. Often, there is too little data left to share across many connections. If the downloaded size is still increasing, let the task continue. The sections below explain why this happens with ordinary file downloads.

Performance profiles#

Profile	Max connections per file	Per-server cap	Min segment	Disk cache
Automatic	16	64	4 MiB	32 MiB
Balanced	16	16	10 MiB	32 MiB
High speed	32	32	4 MiB	64 MiB
Maximum	64	64	1 MiB	64 MiB
Custom	Your choice	Your choice	Your choice	Your choice

Automatic shows default values in its summary. Motrix can adjust connections and segment size for each task based on the download drive and file size. Disk cache is shared by the download engine and can be tuned when it starts. The summary is not a live count of a task’s connections.

The other presets use the values shown. Choose Custom to edit them. A connection count set when adding a task can override the profile for that task.

What the summary means#

• Max connections: the maximum parallel download connections for one file, across its sources.
• Per-server cap: the maximum connections that one file can use to the same server. Both connection limits apply.
• Min segment: controls whether a download range can be split again. It does not make every segment this size.
• Disk cache: memory used to buffer downloaded data before writing it to disk, shared across downloads.

These connection and segment settings apply to ordinary HTTP/HTTPS and FTP downloads. BitTorrent uses torrent pieces and peer settings; see BitTorrent & magnets.

How connections work together#

What is often called a “multithreaded download” means, here, using several network connections to download different parts of one file at the same time.

For an HTTP/HTTPS download, a server that supports partial requests (Range) can send the beginning of a file through one connection, the middle through another, and later parts through others. Incoming data is written to its corresponding position in the file.

The task’s download speed is the combined rate of those connections. For example, four connections receiving 2 MiB/s each add up to 8 MiB/s. This is a simplified example: real connections run at different speeds, which change with network and server conditions.

How splitting works#

Motrix uses aria2 to split downloads automatically. A range smaller than twice the minimum segment size will not be split again. With 1 MiB, that threshold is 2 MiB. Larger ranges can be split while connection limits allow it and the server supports partial downloads.

For a 500 MiB HTTP/HTTPS file, with 64 max connections, a 64 per-server cap, and a 1 MiB minimum segment size:

• Up to 64 connections can download in parallel when the server supports Range requests.
• A per-server cap of 16 limits a single-server download to at most 16 connections.
• A server without partial-download support generally uses one connection.

aria2 assigns ranges dynamically within the connection limits. The settings above allow up to 64 connections; 1 MiB controls splitting, so the file does not become 500 separate, fixed-size download tasks.

1 MiB = 1,048,576 bytes. These settings keep binary units even when file sizes elsewhere use decimal units.

For the underlying rules, see the aria2 manual for connection limits and minimum split size.

Why speed can drop near completion#

With the current engine’s splitting rules, a download can finish like this:

1. Midway through, there is enough work for many connections. They receive data together, giving a higher combined speed.
2. Some ranges finish first, leaving less work to share. A free connection continues if it can take another range. When the remaining ranges are too small to split again, fewer connections keep receiving data.
3. A few connections finish the last remaining data. Total speed now depends on those connections. If one is slow, the last small part can take noticeably longer.

Fewer connections can mean less speed

Each column is one connection. Falling squares show incoming data, assuming 2 MiB/s per connection.

Mid-download4 connections

8 MiB/s

Some ranges complete2 connections

4 MiB/s

Finishing up1 connection

2 MiB/s

Illustration, not measured data. Fast remaining connections may still fill your bandwidth.

These stages have no fixed progress percentages. Connection counts and speed changes depend on the file, server, and network; real downloads need not follow this exact sequence.

Why can’t every free connection help?#

Once a connection has received part of a range, another connection needs a suitable place within the remaining data to start a separate request. The current engine is limited by the minimum segment size and ranges already assigned, so it cannot keep dividing the remaining data indefinitely.

For example, with a 1 MiB minimum segment size, a range smaller than 2 MiB will not be split again. This applies to the range that could be split. Even if a file has a fair amount left in total, small unfinished ranges in different places may not be available for further splitting.

aria2 also tries to switch to a faster request when its conditions allow, but this cannot guarantee full speed for the final range. This finishing behavior follows from the engine’s range allocation and request scheduling rules.

What to do when the last part is slow#

What you see	What to try
Speed is lower, but the downloaded size keeps increasing	Let it continue. Speed measures data arriving each second; the downloaded size is a better way to check whether the task is still making progress.
You already allow 32 or 64 connections, but the last part is slow	The connection count is a ceiling. Raising it usually cannot help when the remaining data cannot be split further.
You want to try reducing the slowdown	Try a smaller minimum segment size in Custom to allow more ranges to be split. This can add request and connection overhead and still cannot guarantee full speed throughout. Automatic is usually a good starting point.
No new data arrives for a long time, or errors keep appearing	Follow Troubleshooting to check task errors, your network, and disk status. If needed, try pausing and resuming. A server that supports resuming can continue the download, but reconnecting does not guarantee better speed.

If the task has moved on to verification or moving the file, it is waiting on local file processing. More download connections cannot speed up those steps. A brief slowdown near completion is common; a prolonged stall needs investigation using the task’s status.

Choosing a profile#

Start with Automatic. If a server rejects connections or downloads become unreliable, try Balanced or reduce the connection limits in Custom. More connections do not guarantee more speed: server limits, network bandwidth, and disk speed still apply. To reserve bandwidth for other apps, use Speed limits.