From owner-freebsd-net@FreeBSD.ORG Thu Sep 18 21:02:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2547BBA2 for ; Thu, 18 Sep 2014 21:02:57 +0000 (UTC) Received: from smtpout101.ehv.onlinespamfilter.nl (smtpout101.ehv.onlinespamfilter.nl [IPv6:2001:4cb8:1:1620:217:21:240:171]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF6673F1 for ; Thu, 18 Sep 2014 21:02:56 +0000 (UTC) Received: from smtp.onlinespamfilter.nl (localhost [127.0.0.1]) by smtp.onlinespamfilter.nl (Postfix) with ESMTP id 3hzVxY5K3gzVV; Thu, 18 Sep 2014 23:02:41 +0200 (CEST) Received: from smtp.debank.tv (145-158-ftth.on.nl [88.159.158.145]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.onlinespamfilter.nl (Postfix) with ESMTPS; Thu, 18 Sep 2014 23:02:41 +0200 (CEST) Received: from smtp.debank.tv (smtp.debank.tv [172.16.143.25]) by smtp.debank.tv (Postfix) with ESMTP id 0CC4A488493; Thu, 18 Sep 2014 23:02:41 +0200 (CEST) Received: from roundcube.debank.tv (roundcube.debank.tv [IPv6:2001:1af8:fe30::41]) by smtp.debank.tv (Postfix) with ESMTP id 9D640488492; Thu, 18 Sep 2014 23:02:40 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 19 Sep 2014 09:02:40 +1200 From: mailinglists@debank.tv To: freebsd-net@freebsd.org, owner-freebsd-net@freebsd.org Subject: Re: Performance problem with slow link behind fast gateway (solved: worked around) In-Reply-To: References: Message-ID: X-Sender: mailinglists@debank.tv User-Agent: Roundcube Webmail/1.0.2 X-Virus-Scanned: ClamAV using ClamSMTP @ debank.tv X-OSF-Virus: CLEAN X-OSF-Outgoing: Innocent X-OSF-Account: 1327 X-OSF-SUM: c444face2d845b6f6cae41d14bebc412 X-OSF-Info: Checked for spam and viruses Cc: Bryan Venteicher X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 21:02:57 -0000 On 2014-09-15 07:55, Bryan Venteicher wrote: > Hi, > > On Tue, Sep 9, 2014 at 4:42 PM, wrote: > >> All, >> >> I'm seeing some performance problems with a slowish VPN connection >> behind >> a fast gateway, the setup looks like this: >> >> |----------------------------------| >> |-----------------------------| >> |client (zandbak) (DSL connection)| ---- 'VPN tunnel' ----- |Gateway >> (vps) using NAT on 1G|------ 'Internet' >> |----------------------------------| >> |-----------------------------| >> >> >> Transfers from the gateway to the client are reasonably fast (easily >> within usable range for me): >> root@zandbak:/usr/home/rob # scp rob@gateway:test_file ./ >> test_file >> 100% 10MB 445.2KB/s 00:23 >> >> >> Transfers from the internet to the gateway are fast: >> root@vps:/usr/home/rob # fetch -4 "http://149.20.53.23/pub/ >> FreeBSD/releases/amd64/amd64/ISO-IMAGES/10.0/FreeBSD-10.0- >> RELEASE-amd64-bootonly.iso" >> FreeBSD-10.0-RELEASE-amd64-bootonly.iso 100% of 209 MB 10 >> MBps >> 00m20s >> >> >> But transfers from the client to the internet through the tunnel are >> showing a very degraded connection speed, the speed jumps up and down >> but >> averages at around 20kBps: >> root@zandbak:/usr/home/rob # fetch "http://149.20.53.23/pub/ >> FreeBSD/ISO-IMAGES-amd64/10.0/FreeBSD-10.0-RELEASE-amd64-bootonly.iso" >> FreeBSD-10.0-RELEASE-amd64-bootonly.iso 0% of 209 MB 8275 >> Bps >> 07h27m >> >> >> I've tried to eliminate some variables: >> -VPN: tinc as a L2 VPN and openVPN as a L3 VPN, results are the same >> -NAT: pf and ipfw, results are the same >> >> I suspect that there's a problem with the fast link receiving too much >> data and once the buffers are full dropping packets although I'm not >> sure >> if this is actually the problem. >> My question is: how can I debug this issue? >> >> >> > ​On the vtnet0 interface in your KVM VM​, disable checksum offloading. > What > KVM/QEMU VirtIO provides as the "checksum" in situation likes this does > not > work well with what FreeBSD expects. Fixing this has been on my todo > list > for awhile, but it is a moderate amount of work to fix this, and > touches > many places in the stack. I have plans to do mbuf related work later > this > year, and was planning to finally fix this issue as well. > > > <--------------SNIP-----------> Thanks Bryan, I can confirm performance with checksum offloading disabled on the vtnet interface is back to expected levels! Rob Evers