Notice that the application uses large UDP packages (close to max size).
UTORRENT 1.8.7 WIN7 PC
When I run our Filemail Desktop application on the exact same server in Sydney which I am testing libTorrent on - and transfer files to the same pc in Norway - I get a transfer speed of over 4 megabytes per sec. It should be at 65000 (max) or at least close to it at all times - at least for this transfer (given latency / package drop scenario). t_upload_mode(true) //No effect?īased on my experience from other UDP based transfer (acceleration) protocols I think it's very detrimental that the UDP package size is reduced all the way down to 10000 at times. Lt::torrent_handle newHandle =s->add_torrent(apr) Sp.set_str(settings_pack::listen_interfaces, string("0.0.0.0:") + to_string(Config::TorrentPort)) Īpr.flags |= lt::add_torrent_params::flag_super_seeding //ONĪpr.flags |= lt::add_torrent_params::flag_seed_mode //ONĪpr.flags &= ~lt::add_torrent_params::flag_auto_managed //OFFĪpr.ti = std::make_shared(pathToTorrentFile) Sp.set_bool(settings_pack::enable_outgoing_tcp, true) Sp.set_bool(settings_pack::enable_outgoing_utp, true) Sp.set_int(settings_pack::connections_limit, 10000) Sp.set_int(settings_pack::unchoke_slots_limit, 999999) Sp.set_bool(settings_pack::allow_multiple_connections_per_ip, true) S = make_unique(lt::fingerprint("LT", LIBTORRENT_VERSION_MAJOR, LIBTORRENT_VERSION_MINOR, 0, 0)) So lowering the gain factor could be a useful test as well.
UTORRENT 1.8.7 WIN7 PATCH
I suspect that by the time the first packet loss is detected, the cwnd has grown too large, and more packets will be lost soon (but apparently not soon enough, as it happens more than one window out, or my patch is wrong). It defaults to 3000 bytes, which is roughly twice as fast as TCP, which uses one segment, i.e. The closer the measured delay gets to the target, the smaller the effective gain will be. Setting the target delay to 1s (from the default 100ms) could have a small impact as it makes the "delay factor" smaller, and the small delay that is detected has much less impact on throttling.Īnother important setting is utp_gain_factor, which is specified as number of bytes per ACK (at 0 delay). Would you mind sharing what you've set the utp_* settings to? However, it looks like you've tweaked the uTP parameters, or at least the target delay.
The problem is that the cwnd pulls back a lot more than cut in half when there's packet loss (or times 0.78 as I updated in that patch). It's not the sawtooth itself that't the problem, it's expected when there's no buffer delay.
0 kommentar(er)
