From patchwork Tue Jan 2 22:40:48 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steffan Karger X-Patchwork-Id: 154 Received: from MBX10D-ORD1.mex06.mlsrvr.com (172.29.1.29) by MBX10C-ORD1.mex06.mlsrvr.com (172.29.1.28) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Mailbox Transport; Wed, 3 Jan 2018 03:42:19 -0600 Received: from MBX12D-ORD1.mex06.mlsrvr.com (172.29.1.35) by MBX10D-ORD1.mex06.mlsrvr.com (172.29.1.29) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 3 Jan 2018 03:42:18 -0600 Received: from gate.forward.smtp.ord1d.emailsrvr.com (161.47.34.7) by MBX12D-ORD1.mex06.mlsrvr.com (172.29.1.35) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Wed, 3 Jan 2018 03:42:18 -0600 Return-Path: X-Spam-Threshold: 95 X-Spam-Score: 0 X-Spam-Flag: NO X-Virus-Scanned: OK X-Orig-To: openvpnslackdevel@openvpn.net X-Originating-Ip: [216.34.181.88] Authentication-Results: smtp21.gate.ord1d.rsapps.net; iprev=pass policy.iprev="216.34.181.88"; spf=pass smtp.mailfrom="openvpn-devel-bounces@lists.sourceforge.net" smtp.helo="lists.sourceforge.net"; dkim=fail (signature verification failed) header.d=sourceforge.net; dkim=fail (signature verification failed) header.d=sf.net; dmarc=none (p=nil; dis=none) header.from=fox-it.com X-Classification-ID: 63a90b8a-f06a-11e7-ab0b-525400a98691-1-1 Received: from [216.34.181.88] ([216.34.181.88:13446] helo=lists.sourceforge.net) by smtp21.gate.ord1d.rsapps.net (envelope-from ) (ecelerity 4.2.1.56364 r(Core:4.2.1.14)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id 37/24-01780-A75AC4A5; Wed, 03 Jan 2018 04:42:18 -0500 Received: from localhost ([127.0.0.1] helo=sfs-ml-1.v29.ch3.sourceforge.com) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.89) (envelope-from ) id 1eWfXw-0004B6-Vc; Wed, 03 Jan 2018 09:41:16 +0000 Received: from sfi-mx-3.v28.ch3.sourceforge.com ([172.29.28.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eWfXv-0004B0-PH for openvpn-devel@lists.sourceforge.net; Wed, 03 Jan 2018 09:41:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Type:MIME-Version:Message-ID:Date:Subject: CC:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=a8YkDDZCuCp3YxFhSairNQ0L667UsxUl0g3TKzfmZPE=; b=fQ0NsH2yUn2GRKvbHIi9fiwOGI BuAYvV2kTEb0xZzLLxUUB3q+j//26NxkF48Fsg1EIVPmY15wFWXKFNwNKqr4SZO3fRgobrfJFO0X+ oZ4cXr6dKp+H8wmZK0R51+RHyYfDhbNdvYuJFo2jbE/YfaAhAink9vixeTzO38hE7hr0=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Type:MIME-Version:Message-ID:Date:Subject:CC:To:From:Sender: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=a8YkDDZCuCp3YxFhSairNQ0L667UsxUl0g3TKzfmZPE=; b=A rMjAoF5epG3xf618WV1vF/xpt4YIYuxCvPlLAJCyiUUY5vEAhDLw8RNIxyqeP1NXHRf/h1FgYa9CM REARbZJouS81E09sT71MZ2JcmxeR6ah6LkeAXI9KaQOWra8+qwxwbeI38GBQbd/Spt8GZRE+cIXU6 ABbagHLMTx4kI4ss=; Received: from ns2.fox-it.com ([178.250.144.131]) by sfi-mx-3.v28.ch3.sourceforge.com with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) id 1eWfXq-0004Fb-4m for openvpn-devel@lists.sourceforge.net; Wed, 03 Jan 2018 09:41:15 +0000 Received: from FOXDFT52.FOX.local (unknown [10.0.0.129]) by ns2.fox-it.com (Postfix) with ESMTPS id 2CBEB1AF75C for ; Wed, 3 Jan 2018 10:41:04 +0100 (CET) Received: from steffan-fox.fox.local (10.0.3.167) by FOXDFT52.FOX.local (10.0.0.129) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 3 Jan 2018 10:41:03 +0100 From: Steffan Karger To: Date: Wed, 3 Jan 2018 10:40:48 +0100 Message-ID: <1514972448-7010-1-git-send-email-steffan.karger@fox-it.com> X-Mailer: git-send-email 2.7.4 X-ClientProxiedBy: FOXDFT52.FOX.local (10.0.0.129) To FOXDFT52.FOX.local (10.0.0.129) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1eWfXq-0004Fb-4m Subject: [Openvpn-devel] [PATCH] reliable: remove reliable_unique_retry() X-BeenThere: openvpn-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: openvpn-devel-bounces@lists.sourceforge.net X-MS-Exchange-Organization-Network-Message-Id: 3203a731-9118-4b73-ae01-08d5528e4800 X-MS-Exchange-Organization-AVStamp-Mailbox: SMEXzs^g;1388100;0;This mail has been scanned by Trend Micro ScanMail for Microsoft Exchange; X-MS-Exchange-Organization-SCL: 0 X-MS-Exchange-Organization-AuthSource: MBX12D-ORD1.mex06.mlsrvr.com X-MS-Exchange-Organization-AuthAs: Anonymous MIME-Version: 1.0 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 :) Signed-off-by: Steffan Karger Acked-by: Gert Doering Acked-by: Gert Doering --- src/openvpn/reliable.c | 26 +------------------------- 1 file changed, 1 insertion(+), 25 deletions(-) diff --git a/src/openvpn/reliable.c b/src/openvpn/reliable.c index 972af61..f484483 100644 --- a/src/openvpn/reliable.c +++ b/src/openvpn/reliable.c @@ -565,30 +565,6 @@ reliable_can_send(const struct reliable *rel) return n_current > 0 && !rel->hold; } -#ifdef EXPONENTIAL_BACKOFF -/* return a unique point-in-time to trigger retry */ -static time_t -reliable_unique_retry(struct reliable *rel, time_t retry) -{ - int i; - while (true) - { - for (i = 0; i < rel->size; ++i) - { - struct reliable_entry *e = &rel->array[i]; - if (e->active && e->next_try == retry) - { - goto again; - } - } - break; -again: - ++retry; - } - return retry; -} -#endif /* ifdef EXPONENTIAL_BACKOFF */ - /* return next buffer to send to remote */ struct buffer * reliable_send(struct reliable *rel, int *opcode) @@ -612,7 +588,7 @@ reliable_send(struct reliable *rel, int *opcode) { #ifdef EXPONENTIAL_BACKOFF /* exponential backoff */ - best->next_try = reliable_unique_retry(rel, local_now + best->timeout); + best->next_try = local_now + best->timeout; best->timeout *= 2; #else /* constant timeout, no backoff */