Fwd: Slow 'real world' network performance

[Kálmán Kiss <kisskamizeg%gmail.com@localhost>]

---------- Forwarded message ---------
From: Kálmán Kiss <kisskamizeg%gmail.com@localhost>
Date: Sun, Nov 2, 2025 at 10:17 PM
Subject: Re: Slow 'real world' network performance
To: Peter Miller <feurry%gmail.com@localhost>

I got curious that tuning those sysctl params dont yield any real improvements even in my very simple network setup (no congestion seen).

Playing on an amd64 windows host <-> netbsd in a virtualbox env, I get a 30-50% increase in average download speed, transfering a big file through ssh/sftp from the vm by using a custom kernel with doubled mbuf size (1024) and mclshift (12) value (param.h).

My only other modifications are maxusers 128 in the kernel config, and setting cubic congestion algo in sysctl.

I cant say I fully understand what Im doing, but for me it seems the mbuf params should be configurable at boot or with sysctl? :)

Anyway, I plan to test this customizations in my home network with various clinent hosts and OSes.

On Wed, Oct 29, 2025 at 2:45 AM Peter Miller <feurry%gmail.com@localhost> wrote:

On Sat, Oct 25, 2025 at 4:09 PM Michael van Elst <mlelstv%serpens.de@localhost> wrote:
> The examples given here are already all you can tune. Basically you
> bump the buffer sizes to allow for larger TCP windows.
...
> This is the major reason for your observations (and shows that
> NetBSD has room for improvement).

Thank you, good to know.

Since I get good speeds with FreeBSD I figure the sysctl settings
ought to be a good reference. Hopefully I got the right sysctls since
the naming is a bit different.

... 

Here's the /etc/sysctl.conf I tested.

kern.sbmax=2097152
kern.somaxkva=536870912
net.inet.tcp.sendbuf_max=2097152
net.inet.tcp.recvbuf_max=2097152

net.inet.tcp.init_win=10
net.inet.tcp.init_win_local=10
net.inet.tcp.congctl.selected=cubic
net.inet.tcp.delack_ticks=40

hw.vioif0.tx.process_limit=512
hw.vioif0.rx.process_limit=512

And I got very similar results. The biggest difference by far is
network congestion etc. that's out of my control.

Thanks for the help.

--
Thanks
Peter