![]() 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. 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 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |