Since a file chunk can only be shared once it's completed, it's better for files spreading if you sent chunks quickly to few uploaders (so that they can start sharing those chunks too) than slowly to many peers.
When dynamic_slots is enabled, MLdonkey will dynamicly adjust the number of upload slots, making sure their combined bandwith is less or equal to max_hard_upload_rate. That said, the number of upload slots will fluctuate between 3 and max_upload_slots.
Default value for dynamic_slots is false.
This option is stored in downloads.ini
> set dynamic_slots true
This is an experimental feature.
Dynamic slots implementation (in commonUploads.ml) has two main components:
- A "long term rate estimator", that takes the maximum of observed uplink usage over some recent period
- A slot allocator, that compares the long term estimator result with instantaneous uplink usage. When, over some period, the difference is bigger than the target bandwidth for each slot, a new slot is opened. Since an "observation" period is necessary before a slot is opened, opening many slots could be slow. So the allocator opens slots in clusters of linearly increasing size: if, after a second period, the bandwidth is still underused, it will open 2 slots at once, etc.
That algorithm requires that the uplink usage does not fluctuate too much, or the slot allocator will try to compensate by opening more slots than strictly necessary. Examples of such cases could be (temporary) competition with other network traffic, and maybe also large uplink capacities, where the constant unused bandwidth trigger may become too small (? no hardware to test that second hypothesis).
Feel free to suggest ideas of improvement.