From nobody Sun Mar 17 00:55:21 2024 X-Original-To: freebsd-current@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 4Ty0095vqMz5DvTh for ; Sun, 17 Mar 2024 00:55:37 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ty0056TQYz4LXH; Sun, 17 Mar 2024 00:55:33 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp designates 153.125.133.21 as permitted sender) smtp.mailfrom=junchoon@dec.sakura.ne.jp Received: from kalamity.joker.local (123-1-21-232.area1b.commufa.jp [123.1.21.232]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 42H0tL6b026335; Sun, 17 Mar 2024 09:55:22 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 17 Mar 2024 09:55:21 +0900 From: Tomoaki AOKI To: tuexen@freebsd.org Cc: freebsd-current@freebsd.org Subject: Re: Request for Testing: TCP RACK Message-Id: <20240317095521.0936373c49988170dbcb2703@dec.sakura.ne.jp> In-Reply-To: <20231119040101.503d44475182e9721081179e@dec.sakura.ne.jp> References: <42C327BD-6CE4-43AA-A1AE-3BEC08D623DB@freebsd.org> <2bbfcf68-3249-45c7-a8e5-af7115a1ccfe@gmail.com> <20231118083704.3ebc17eb8f392ceae33f65f7@dec.sakura.ne.jp> <20231119040101.503d44475182e9721081179e@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.08 / 15.00]; NEURAL_HAM_LONG(-0.99)[-0.991]; NEURAL_HAM_MEDIUM(-0.87)[-0.871]; NEURAL_HAM_SHORT(-0.51)[-0.514]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:153.125.133.16/28]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; HAS_ORG_HEADER(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4Ty0056TQYz4LXH On Sun, 19 Nov 2023 04:01:01 +0900 Tomoaki AOKI wrote: > On Sat, 18 Nov 2023 09:50:43 +0100 > tuexen@freebsd.org wrote: > > > > On Nov 18, 2023, at 00:37, Tomoaki AOKI wrote: > > > > > > On Fri, 17 Nov 2023 18:51:05 +0100 > > > tuexen@freebsd.org wrote: > > > > > >>> On Nov 17, 2023, at 17:06, Johan Hendriks wrote: > > >>> > > >>> I am running the rack stack for quiet some time now on a baremetal machiene and never had problems. > > >>> Also use pf. This is a test machine so not a lot happening on it. > > >>> > > >>> Are there any thing we can test? Do we have some test scripts we can run? > > >> We are actually interested in feedback about using the stack in whatever > > >> use case you use TCP for. The stack has been tested with the Netflix use > > >> case, but not so much with others. That is why we ask for broader testing. > > >> > > >> Best regards > > >> Michael > > > > > > Are there any difference regarding with performance between main and > > > stable/14? If so, please ignore below. > > > > > > I have stable/14 environment which is configured to be able to switch > > > to TCP RACK and experienced huge performance loss when writing > > > a large file to smbfs share on commercial NAS. CC is cubic. > > > Testing large archive on the smbfs share doesn't seem to be > > > affected. > > > > > > Comparison between default (freebsd) and rack TCP stack using > > > sysutils/clone on stable/14 at commit 7d1321288ad9, amd64. > > > Last 3 lines of outputs from clone (upload to NAS) are shown. > > Thank you very much for testing. This is what we are looking > > for. Would it be possible to repeat the test using NewReno as > > the CC? > > > > Best regards > > Michael > > Sure. Here we go! > > sysctl net.inet.tcp.functions_default > net.inet.tcp.functions_default: freebsd > sysctl net.inet.tcp.cc.algorithm > net.inet.tcp.cc.algorithm: newreno > Umounted and remounted smbfs share. > > 1 item copied, 2343.1 MB in 37.65 s -- 62.2 MB/s > Leaked memory: 0 bytes > No errors occured. > > > sysctl net.inet.tcp.functions_default > net.inet.tcp.functions_default: rack > Umounted and remounted smbfs share. > > 1 item copied, 2343.1 MB in 905.17 s -- 2.6 MB/s > Leaked memory: 0 bytes > No errors occured. > > > sysctl net.inet.tcp.functions_default > net.inet.tcp.functions_default: freebsd > Without umount and remount to reproduce previous oddness, maybe caused > by keep-alive. > > 1 item copied, 2343.1 MB in 897.67 s -- 2.6 MB/s > Leaked memory: 0 bytes > No errors occured. > > > Umounted and remounted, without change for CC and TCP stack. > > 1 item copied, 2343.1 MB in 37.43 s -- 62.6 MB/s > Leaked memory: 0 bytes > No errors occured. > > > All test are proceeded simultaneously. So the last one is with > CC=newreno and TCP stack=freebsd. > > Not exactly recorded, but testing transferred file by > diff -u -p -N was roughly 30MB/sec, while roughly 25MB/sec with > CC=cubic. > > > > > > > > Before switching to rack: > > > 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s > > > Leaked memory: 0 bytes > > > No errors occured. > > > > > > Unmount the smbfs share, switch to rack, and after remount: > > > 1 item copied, 2342.4 MB in 926.59 s -- 2.5 MB/s > > > Leaked memory: 0 bytes > > > No errors occured. > > > > > > Switch back to freebsd (default) without unmounting: > > > 1 item copied, 2342.4 MB in 906.94 s -- 2.6 MB/s > > > Leaked memory: 0 bytes > > > No errors occured. > > > > > > Unmount and remount the smbfs share: > > > 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s > > > Leaked memory: 0 bytes > > > No errors occured. > > > > > > > > > Regards. > > > > > > -- > > > Tomoaki AOKI > > > -- > Tomoaki AOKI Just a follow up. This situation does not changed on stable/14, amd64 until commit a15b8e32942b2cbf70c7fc71e9c82d2b292e82c3. (So I've never reported again until now. Not tested on every updates.) tcphpts.ko is loaded. Note that options RATELIMIT and options TCPHPTS are dropped when changes to RACK is MFC'ed and added tcphpts_load="YES" in /boot/loader.conf instaad. Another note: Differences between CC=newreno and CC=cubic on testing transferred file seems to be just a fudge factor. both vaies mostly between the two values which I've previously reported. -- Tomoaki AOKI