Date: Tue, 31 Jan 2023 13:31:29 -0500 From: Paul Mather <paul@gromit.dlib.vt.edu> To: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> Cc: stable@freebsd.org Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? Message-ID: <282AF730-E5E0-4A50-9F47-E7301B36E5C8@gromit.dlib.vt.edu> In-Reply-To: <4ed8b724-041f-f561-ae60-ab966aefbb68@plan-b.pwste.edu.pl> References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> <4ed8b724-041f-f561-ae60-ab966aefbb68@plan-b.pwste.edu.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 30, 2023, at 4:59 PM, Marek Zarychta = <zarychtam@plan-b.pwste.edu.pl> wrote: > W dniu 30.01.2023 o 22:17, Paul Mather pisze: >> TL;DR: When working from home, I can max out my residential 200 Mbit = network connection when downloading from remote Linux hosts at $JOB but = only manage about 20% of my max residential connection speed when = downloading from remote FreeBSD hosts at $JOB. When at $JOB, both = FreeBSD and Linux hosts have no problem saturating their GbE connections = transferring between each other. Why is this and how can I debug and = fix it? >>=20 >> I have a 200 Mbit residential cable connection (Xfinity, 200 Mbit = down/~10 Mbit up). I've noticed recently that I can easily get 10--20 = MB/s download speeds when transferring data from Linux hosts at work but = when I try to download that same data from the FreeBSD hosts I use the = speed usually tops out at 3--4 MB/s. These are Linux and FreeBSD hosts = that are on the same subnet at work. Transfers from the FreeBSD hosts = at work (within-subnet and within-site) are fine and match those of the = Linux hosts---often 112 MB/s. So, it just appears to be the traffic = over the WAN to my home that is affected. The WAN path from home to = this subnet is typically 15 hops with a typical average ping latency of = about 23 ms. >>=20 >> The FreeBSD hosts are a mixture of -CURRENT, 13-STABLE, and = 13.1-RELEASE. I had done some TCP tuning based upon the calomel.org = <http://calomel.org/>; tuning document = (https://calomel.org/freebsd_network_tuning.html), but removed those = tuning settings when I noticed the problem but the problem still = persists. The only remaining customisation is that the 13-STABLE has = "net.inet.tcp.cc.algorithm=3Dcubic". (I notice that -CURRENT now has = this as default so wanted to try that on 13-STABLE, too.) The FreeBSD = systems are using either igb or em NICs. The Linux systems are using = similar hardware. None has a problem maintaining local GbE transfer = speeds---it's only the slower/longer WAN connections that have problems = for the FreeBSD hosts. >>=20 >> It seems that Linux hosts cope with the WAN path to my home better = than the FreeBSD systems. Has anyone else noticed this? Does anyone = have any idea as to what is obviously going wrong here and how I might = debug/fix the FreeBSD hosts to yield faster speeds? My workaround at = the moment is to favour using the remote Linux hosts for bulk data = transfers. (I don't like this workaround.) >>=20 >> Any help/insight is gratefully appreciated. >>=20 >> Cheers, >>=20 >> Paul. >>=20 > 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? Cheers, Paul.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?282AF730-E5E0-4A50-9F47-E7301B36E5C8>