Good news again! I managed to increase client->server scp speeds to the expected 8 MB/s by specifically increasing recvspace:
net.inet.tcp.recvspace=4194304 >From what I understand, the TCP window should've been growing automatically, and since my recvbuf_max is already 16MB, I didn't think recvspace would be the bottleneck. Apparently, that's not the case when SSH receives data? Previously, both recvspace and sendspace were 262144, with both having a max of 16777216. Other traffic managed to scale and use the maximum size fully, including SSH when sending. But for some reason, SSH requires a larger initial recvspace when receiving. It's the only exception so far. Either way, here are my current tunables: kern.sbmax=16777216 net.inet.tcp.recvspace=4194304 net.inet.tcp.sendspace=4194304 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_inc=262144 net.inet.tcp.sendbuf_inc=262144 net.inet.tcp.congctl.selected=cubic SSH, HTTP and iperf3 are now performing very well in both directions. I think I have no more complaints. I'm definitely ready to put NetBSD into production and I'm pretty happy, because I fell in love with the system the moment I first installed it. I want to write a follow-up tomorrow in my blog so people don't wrongly assume there's something inherently wrong with NetBSD's networking stack. Thank everyone who helped me, I'm definitely a NetBSD fan now. Best regards, - z411
