Re: Request for Testing: TCP RACK

On Sun, 19 Nov 2023 04:01:01 +0900
Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:

> On Sat, 18 Nov 2023 09:50:43 +0100
> tuexen@freebsd.org wrote:
> 
> > > On Nov 18, 2023, at 00:37, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
> > > 
> > > On Fri, 17 Nov 2023 18:51:05 +0100
> > > tuexen@freebsd.org wrote:
> > > 
> > >>> On Nov 17, 2023, at 17:06, Johan Hendriks <joh.hendriks@gmail.com> 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    <junchoon@dec.sakura.ne.jp>
> 
> 
> -- 
> Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>

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    <junchoon@dec.sakura.ne.jp>