perf: raise transfer defaults and stop uploads sleeping on their slot
The slot cap merged from master defaults to 2 uploads, and the CLI capped downloads at 5. Those are the numbers you pick when your own bandwidth is the scarce resource, but a Soulseek transfer is paced by the peer on the other end — usually a few hundred KiB/s — so what fills a modern link is many transfers at once, not faster ones. Upload slots go to 10, downloads to 20. The queue itself stays: privileged users being able to jump it is a condition of being a tolerated third-party client. serve_file also slept half a second after the last byte so the downloader could drain before the socket closed. With a cap that is time no other peer can use, and 64 uploads over 10 slots paid it six times over. A half-close says "that is the whole file" and TCP still delivers everything written before the FIN. Measured with 64 waiting peers: 2 slots 24.2s, 8 slots 6.2s, 32 slots 3.1s; at 10 slots the linger alone was 5.4s to 3.05s.
This commit is contained in:
@@ -246,7 +246,13 @@ pub struct Resolved {
|
||||
|
||||
pub const DEFAULT_SERVER: &str = "server.slsknet.org:2416";
|
||||
pub const DEFAULT_LISTENER_PORT: u16 = 2234;
|
||||
pub const DEFAULT_MAX_CONCURRENT_DOWNLOADS: usize = 5;
|
||||
/// How many downloads run at once by default.
|
||||
///
|
||||
/// Downstream is the abundant direction, and a Soulseek transfer is paced by
|
||||
/// the sending peer — usually a few hundred KiB/s — so filling a modern link
|
||||
/// takes many transfers at once, not faster ones. Twenty at a typical peer rate
|
||||
/// is tens of MiB/s, and costs twenty threads and sockets, which is nothing.
|
||||
pub const DEFAULT_MAX_CONCURRENT_DOWNLOADS: usize = 20;
|
||||
pub const DEFAULT_SEARCH_TIMEOUT: u64 = 10;
|
||||
|
||||
/// Layer CLI/env values over the config file over defaults.
|
||||
|
||||
Reference in New Issue
Block a user