From nobody Tue Jan 31 20:38:25 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5xhp2KxBz3cFJX for ; Tue, 31 Jan 2023 20:38:34 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5xhn5bRzz3LLW for ; Tue, 31 Jan 2023 20:38:33 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; none Received: from [IPV6:2a02:22e0:cf00:1ff:b17d:1e6f:50a2:6f71] (mzar@[IPv6:2a02:22e0:cf00:1ff:b17d:1e6f:50a2:6f71]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 30VKcRc3002504 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 31 Jan 2023 21:38:28 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1675197509; bh=J09Y0RNsltBEZkhlKkoiDO1nnqVUBQxyR2uniQVghRg=; h=Date:To:Cc:References:From:Subject:In-Reply-To; b=gi17opZcyEfeA9dvIbZgIwmstdsiVpim8O4YXN3FmzCi4IKSjnQkfqLhL+1RDZg5j wumWtZGbylDw15bZBrtD84OO4gNzvbchKA27z6vC/hGxg5CNolw+aeCfhJn1oPNxQJ XJCtHTZ6GoAXLo8dzrdZdUWl52zDSe6YzoAtDlEpcobZMiTA0c0CX6quZx+GrBWovD ANzzUnMj7AAc5zHG0VsKE2NKcUppZNYlxnCVMD8cmXGhfGif2Hg6NrjOu9NHAchVRz DXv/81fwktMIe0kj0993gxtYLa1K4Xg8ksTeG8sqRZGff6Uqzb2B39AVOc7g7sjzrW XuvPkKy/jA8IQ== Message-ID: <2ed582b9-b544-74bb-2047-99d04924b46b@plan-b.pwste.edu.pl> Date: Tue, 31 Jan 2023 21:38:25 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 To: Paul Mather Cc: stable@freebsd.org References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> <4ed8b724-041f-f561-ae60-ab966aefbb68@plan-b.pwste.edu.pl> <282AF730-E5E0-4A50-9F47-E7301B36E5C8@gromit.dlib.vt.edu> Content-Language: en-US From: Marek Zarychta Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? In-Reply-To: <282AF730-E5E0-4A50-9F47-E7301B36E5C8@gromit.dlib.vt.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4P5xhn5bRzz3LLW X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N W dniu 31.01.2023 o 19:31, Paul Mather pisze: >> While playing with different mod_cc(4) might bring some improvement, to get a real boost I'd suggest enabling tcp_rack(4) if feasible. > > I am interested in trying this out, but believe it is more feasible in my case for the -STABLE and -CURRENT systems I am using, not so much for the -RELEASE systems that are kept up to date via binary freebsd-update updates. My reading of the tcp_rack(4) man page is that you have to build a custom kernel as, unlike the cc_* congestion control algorithms, the loadable tcp_rack module is not built by default. Is that an accurate reading? > Yes, this gift from Netflix is probably better suited for -STABLE and -CURRENT as easier to set up there. There is an excellent, up-to-date article about it by Klara Systems writers[1]. From my experience tcp_rack(4) is well suited for congested, lossy or redundant network paths where loses, duplicated packets or races between packets occur. Not a panacea, but very performant TCP stack based on the _fair_  algorithm. In some instances, it might help you to saturate the bandwidth of the link. TCP algo can be loaded/unloaded/changed on the fly. In FreeBSD 14-CURRENT you can change it on an active socket with tcpsso(8) utility, in FreeBSD 12 and 13 you have to restart the app bound to the socket. Please feel free to play with TCP stacks and congestion algos with the help of benchmarks/iperf3 to find out what prevents the link from being saturated and give us some feedback here. [1] https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/ Cheers -- Marek Zarychta