Default "Slot Allocation" value (2 kB/s) is outdated for modern connections #896

Summary

The default upload Slot Allocation is hardcoded to 2 kB/s. This value dates
back to the dial-up / early-ADSL era and produces poor upload distribution on any
modern broadband connection. I'd suggest raising it to a more sensible default
(~10 kB/s).

How the setting works

SlotAllocation is the target upload bandwidth (in kB/s) per upload slot.
aMule derives the number of simultaneous upload slots from it in
CUploadQueue::GetMaxSlots() (src/UploadQueue.cpp:304):

• Upload limited: slots = MaxUpload / SlotAllocation
• Upload unlimited: slots = currentUploadRate / SlotAllocation + 2

The result is clamped to MAX_UP_CLIENTS_ALLOWED = 250
(src/include/protocol/ed2k/Constants.h).

Why 2 kB/s is too low today

Using the current worldwide average upload speed of ~15 Mbps (≈ 1920 kB/s):

With the default of 2, a globally average connection already slams into the
hard 250-slot ceiling. The upload is split into hundreds of tiny slots, each
carrying only a few kB/s, which maximizes TCP/protocol overhead and gives every
peer an almost useless transfer rate. A value of ~10 kB/s keeps the slot count
well below the cap and gives each peer a usable speed, while still serving plenty
of distinct clients for the credit system.

Why 10 kB/s, and not a higher value?

A higher value (30–50) sounds like "fewer but faster peers", but on the ed2k
network that is actually worse as a default:

1. The credit system rewards breadth, not per-peer speed. Credits are earned
   per peer: uploading to a client raises your priority in that client's
   queue. Serving more distinct peers means more sources prioritize you, which is
   what actually improves your download. A high Slot Allocation serves few peers
   at once, so credit is built with very few of them — defeating the main benefit.

2. Individual ed2k peers are slow. A single remote peer rarely pulls more than
   ~10 kB/s from one source (its own limits, queue rank, multi-source downloading).
   Allocating 30–50 kB/s per slot mostly leaves bandwidth unused, since the peer
   can't absorb it.

3. A default must fit the whole user base, not just fiber. On a slow line
   (2 Mbps ≈ 256 kB/s) a default of 30 yields only ~8 slots — too few. With 10 it
   yields ~25, which is healthy. A value of 10 keeps the slot count reasonable from
   ~2 Mbps up to fast lines without hitting the 250-slot cap. Users with fast
   symmetric uplinks can raise it manually.

4. 10 kB/s is well above the useful minimum. It is far above eMule's historic
   per-client floor (~2.4 kB/s), so each slot completes 180 KB blocks at a steady
   pace (~18 s/block) without starving.

In short, 10 is chosen as a conservative universal default — high enough to fix
the slot fragmentation on fast connections, low enough not to hurt slow ones — not
a ceiling on what users may configure.

Inconsistency in the current code

The persisted default and the UI control default don't match:

• src/Preferences.cpp:1063
NewCfgItem(IDC_SLOTALLOC, (MkCfg_Int( "/eMule/SlotAllocation", s_slotallocation, 2 ))); → default 2
• src/muuli_wdr.cpp:1336
new wxSpinCtrl( parent, IDC_SLOTALLOC, "4", ..., 1, 100000, 4 ); → default 4

Proposed change

1. Raise the persisted default in src/Preferences.cpp:1063 from 2 to 10.
2. Align the UI spin control default in src/muuli_wdr.cpp:1336 to the same value.

References

I've been very conservative with global upload speed of 15 Mbps. Real is higher => https://www.speedtest.net/global-index