Am 03.01.18 um 10:40 schrieb Steffan Karger: > This function has been in the code since 2005, and enabled since 2010, but > it's not clear why we'd want this behaviour. > > Running some simple tests, where I simulate an server->client link of > 1mbit with 30ms delay and 1% packet loss, and a client->server link of > 200kbit, 200ms delay, I get the following connection setup times over > 100 runs when pushing ~100kb of options (e.g. a lot of routes): > > With reliable_unique_retry: Mean: 14.9 s, Std dev: 9.1 s > Without reliable_unique_retry: Mean: 11.8 s, Std dev: 5.8 s > > For more standard push sizes (~1kb), the effect is of course smaller: > > With reliable_unique_retry: Mean: 2.7 s, Std dev: 0.6 s > Without reliable_unique_retry: Mean: 2.6 s, Std dev: 0.7 s > > This shows that this mechanism hurts performance under packet loss > conditions. (Without packet loss, there are no retransmissions and this > has no influence, of course.) Querying the openvpn collective memory > (read: James, David and Gert) did not yield any arguments to keep it. > James even mentioned that OpenVPN 3 doesn't include this mechanism. > > So, improve our connection setup performance by removing some code :) >
Probably coming from an Internet age where connections were modems and scaling down even to really low speed was a good and standard approach. TCP for example can scale to to 1 packet per 300s Arne ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel