From nobody Tue Jan 31 22:03:08 2023 X-Original-To: freebsd-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 4P5zZp3mr4z3cR1H for ; Tue, 31 Jan 2023 22:03:30 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.ipv6.vt.edu [IPv6:2001:468:c80:a103:2:5000:5555:5555]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5zZp2ww1z3rMR for ; Tue, 31 Jan 2023 22:03:30 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 7B0255167E; Tue, 31 Jan 2023 17:03:19 -0500 (EST) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? From: Paul Mather In-Reply-To: Date: Tue, 31 Jan 2023 17:03:08 -0500 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> To: David <2yt@gmx.com> X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4P5zZp2ww1z3rMR X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1312, ipnet:2001:468:c80::/48, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jan 31, 2023, at 10:39 AM, David <2yt@gmx.com> wrote: > On 1/30/23 16:30, Matt Garber wrote: >> > Any help/insight is gratefully appreciated. >> > >> > Cheers, >> > >> > Paul. >> > >> sysctl net.inet.tcp.cc.algorithm=3Dhtcp >> I would set "htcp" on the server and home computer to improve >> through in >> your type of situation. >> There may be other FreeBSD sysctls that have bad defaults in this = scenario and could be better tuned, but I doubt changing the CC = algorithm at this point is the problem =E2=80=94 at least not so much a = problem that=E2=80=99s causing throughput to be reduced so drastically. = Happy to be wrong if that does help things quickly and easily, though. >> (Since OP mentioned that FreeBSD CC was set to CUBIC, that would = match what the Linux boxes are using by default, too, unless they=E2=80=99= ve been changed to something newer like BBR=E2=80=A6 so seems like CUBIC = *should* be performing fine on this WAN link, and the difference is = something else.) >> =E2=80=94Matt >=20 > I love FreeBSD and very much appreciate the efforts of those people = much smarter. But... I don't think the defaults get enough testing in = real world conditions. >=20 > I came across Paul's issue several years ago and spent a few a hours = testing and found the defaults performed very well on a LAN but could = perform terribly on a many hop WAN. HTCP performs marginally worse on a = LAN or close WAN connection, but much much better on a many hop WAN = connection. >=20 [[...]] > In my opinion HTCP is a better default for the current state of the = internet. It looks like they already changed the default from NewReno to CUBIC in = FreeBSD-CURRENT. I agree with your observation about the defaults vs. real world = conditions. As you observed, I also get great performance in a = high-speed LAN, but not so much in a many-hop WAN to an asymmetric ISP = connection. I actually started down this rabbit hole when I noticed I couldn't = manage more than about 3--4 MB in a single stream and thought my ISP was = throttling me. But then I noticed I would actually get fast/maximum = speeds, e.g., when doing "brew upgrade -v" and Homebrew would be = downloading packages, and so then wondered whether they were throttling = non-HTTP traffic. That led me to discover that even HTTP downloads were = slow to the FreeBSD servers I use remotely at $JOB and, furthermore, = that all traffic to Linux systems I use at $JOB didn't seem to be = throttled or incapable of getting maximum single stream bandwidth = matching my ISP's quoted speeds. :-\ I accept that this may just be a peculiarity of my local and remote = setup, and so appreciate the help and suggestions people have offered in = trying to debug the issue. Cheers, Paul.=