Short answer: change two things and leave the rest alone.
The defaults are not arbitrary — they were arrived at by measurement, and most of them are already at the point where more does not mean better. The two that depend on facts only you know are your connection limit and where downloads go.
The two that matter
1. Max Connections — set it to your plan's limit
Settings → Connection → Max Connections. Default 60.
This is the single hard cap the whole app obeys. It limits both uploading and downloading, so setting it once adjusts everything.
Put in the number your provider's plan allows. If your plan says 50, put 50.
Getting it wrong hurts in both directions:
- Too high → the provider refuses the extras. You get
502 too many connectionserrors and less throughput than a correct value. - Too low → you leave capacity unused for nothing.
More than your plan allows is never faster. It is just errors.
2. Default download location — put it on a fast disk
Storage page → Default download location.
A local SSD or NVMe if you have one. Network drives work but are frequently the slowest link in the chain, and people who assume their internet connection is the limit are often wrong.
The Model a download (TB) control checks a planned download against free space before you commit.
And if you have a second provider account, add it
Settings → Connection → Multi-account posting and Multi-account downloading.
Two accounts have two connection limits and they add up. This is the most effective performance change available, and it beats every tuning value in this guide, because it raises your provider's ceiling rather than shuffling work beneath it.
Everything else, and why to leave it
Upload
| Setting | Default | Leave it because |
|---|---|---|
| Upload Connections | 60 | Clamped by Max Connections anyway. Set that instead. |
| Batch Multiplier | 2 | Batch is connections × 2. Larger does not post faster; it just queues more. |
| Post Queue Size | 300 | Already deeper than the pipeline drains. |
| Article Size | 850 KB | Must stay above the segment size plus overhead. Changing it independently breaks the relationship. |
| Segment Size | 768 KB | Read-only, and deliberately. It is part of the published format. |
If your upload is slow, none of these is the reason. Upload speed is governed
by how long your provider takes to acknowledge each posted article, and the spread
between providers is enormous: measured across four major backbones with identical
software and identical articles, the time to return 240 article posted ranged
from 77 ms to 2,654 ms. That works out at roughly 8.3 MB/s per connection on
the fastest and 0.25 MB/s on the slowest — a difference of more than thirtyfold,
from nothing but the choice of provider.
On the slowest of them, a connection spends about 98% of each article waiting for the acknowledgement: the article body itself takes around 33 ms on the wire, and the remaining two and a half seconds are the provider thinking about it.
So a slow upload at a healthy connection count means one of two things, and neither is a setting on this page:
- Your provider is slow to acknowledge. A different provider is dramatically faster. This is the largest single factor in publishing speed.
- You are at your connection limit. A second account adds another one.
Download
| Setting | Default | Leave it because |
|---|---|---|
| C++ Downloader Processes | 20 | 20 × 3 = 60 connections, validated on a gigabit link |
| Connections Per Process | 3 | The product is what matters, and it is clamped by Max Connections |
| SSL Read Timeout | 120 s | Generous on purpose, so a slow provider is not mistaken for a dead one |
For context on what the defaults reach: measured on a gigabit link, a 32 GiB download sustained 91.5 MB/s, and streaming through a mounted share sustained 110 MB/s. Raw provider throughput plateaued at about 94 MB/s at 30 connections on that link — beyond which more connections bought nothing.
That last point is the one worth absorbing: the plateau is real. If you are already at your plan limit and not seeing what you expect, the ceiling is your provider or your disk, not a number in this app.
Final check of very large files
Settings → Performance. Default Automatic (recommended).
The one performance setting genuinely worth changing, and only in one situation.
| Option | When |
|---|---|
| Automatic | Default. Decides per file by size. |
| Check during the download | The final pass is slow on your destination and you would rather overlap it |
| Check after the download | You prefer one clean pass at the end |
| Skip the final check | Fast local disk you trust, and you want the time back |
If a large download spends a long time on its final check, Check during the download is the right change — same protection, overlapped with the transfer.
Skipping it is a real trade, not a free win: every piece is still verified as it arrives from the network, but you lose the confirmation that your storage kept what arrived — which is exactly what a flaky drive or a dropping network share gets wrong. Full reasoning: Verify and repair.
Streaming Prefetch Window
Settings → Performance. Default 0, meaning automatic.
Raise it only if playback from a mounted share stutters while your connection is clearly not saturated. It controls how far ahead a stream reads.
Automatic already scales with your connection budget. A hand-set value that is too high steals connections from everything else.
Publish cache
| Setting | Default | |
|---|---|---|
| Max Cache (GB) | 100 | Scratch space ceiling while publishing |
| Cache Delete Mode | Auto | Resolves per folder from available headroom |
| Pack Compression | zstd | Roughly 8.6× faster than gzip on real data, with a slightly better ratio |
Lower Max Cache if 100 GB of scratch is too much for your disk. There is no reason to change the other two — zstd is faster and smaller, and Auto already adapts.
Redundancy: what to actually change
Settings → Advanced. This is where a deliberate change is genuinely worth making.
| Setting | Default | Recommendation |
|---|---|---|
| Content Redundancy | 3 | Fine for most things. Raise for anything irreplaceable. |
| Core Index Redundancy | 1 | Raise this to 2 or 3. |
| Access Layer Redundancy | 1 | Raise with the above on private shares. |
| Manifest Redundancy | 1 | Raise with the above. |
Why raise the control layer specifically. Content redundancy protects your files; the control layer is the catalogue, the access data and the manifest — the small articles that describe the share. At a single copy, losing one of them breaks that layer, and a share whose catalogue is gone cannot be opened even if every byte of content is still healthy.
They are tiny. Duplicating them costs almost nothing in time or storage, and it protects against the failure that loses everything rather than a part.
Provider Retention (days) — default 4000. Set it to what your provider actually advertises. It is not a control, it is a declaration: the app uses it to warn you before a published share ages out.
Do not change these
Segment Size and Pack Threshold are read-only. They are part of the published format, and consumers rely on them.
Article Options — subject, from address, yEnc name — are randomised on purpose, so posts carry nothing identifying. Making them meaningful would put information on Usenet that the encryption otherwise keeps off it.
Check Options govern post-verification retries. The defaults tolerate providers that are slow to make an article retrievable, which is normal behaviour and not a fault.
Before you change anything, measure
Help & Support → Check your speed measures three things separately:
- What your provider delivers
- How fast your download drive writes
- How fast it reads
Then it says in plain language which one is the ceiling.
Run this before tuning. The common outcome is that the destination disk is the limit, in which case no setting in this app will help and moving the download somewhere else will. The second most common is being at your provider's connection cap, where the answer is a second account.
The result has a Copy button that builds a report you can paste into an email to support. See When something is wrong.
A short summary
| Do | Set Max Connections to your plan's limit |
| Do | Put downloads on a fast local disk |
| Do | Add a second provider account if you have one |
| Do | Raise core index / access / manifest redundancy to 2–3 |
| Consider | "Check during the download" if final checks are slow |
| Consider | Lowering Max Cache if 100 GB of scratch is too much |
| Don't | Raise connections above your plan |
| Don't | Change article or segment sizes |
| Don't | Tune anything before running the speed test |
Next
- When something is wrong — measure first
- Verify and repair — the redundancy reasoning in full
- How UsenetShare works — why connections are the ceiling