[email protected] (z411) writes: >https://u.omaera.org/e1000.png
>All operating systems simply do better with E1000, but VirtIO caps >NetBSD in particular to 1 MB/s even when tuned, so while other OSes do >"okay" with VirtIO, NetBSD has serious trouble with it. In a LAN setup, vioif sends about 700MBit/s and the interface reports regular errors (output packet drops). Output packet drops occur, when the host does not offer the virtio slots for the DMA segments of a packet. So that would put qemu on the host being responsible. Receiving gets barely about 500Mbit/s with no interface errors reported. But if the host is too slow, it probably drops packets silently and the guest doesn't see that. >On 3/7/26 03:41, Michael van Elst wrote: >> It would be interesting to see how that affects your setup. >I tried your patchset. Sadly I don't think I saw much improvement. >Here's a worst case measurement (xpl files inside): You should have seen faster congestion recovery. I don't have a very fast WAN connection for testing, but in a simulated WAN with 100ms RTT, the patch allows me to get close to 1Gbit/s. >I found a new issue though: receiving files with SCP from the >server->client is fast, but when sending files to the server it only >sends 255KB and then it stalls for about half a minute, then sends the >rest at a slow pace (around 200-300 KB/s). If I send it using legacy SCP >(-O flag) the initial stall doesn't happen, but it's still slow. >The server has big recv buffers and it has no trouble downloading >(downloads using ftp(1) are very fast), it's just SCP. If that's the speed reported by scp itself, it's an artefact of openssh. The new SFTP method reports speed by counting bytes reported by the peer as written to disk. Any kind of buffering creates a start penalty, so you see almost nothing being transmitted (even a "stalled" warning) before the first reports are collected and the speed average goes up. The legacy SCP method reports speed by counting the bytes written to the network. That's pretty close to the network speed right from the start. The actual speed of both methods is the same, this is just about what you see in the progress report. When legacy SCP is still slower than wire speed, then it's either CPU limitation, or the fact that ssh uses it's own kind of buffering that limits what TCP can do. There is a "high performance networking" patch to ssh (that the NetBSD ssh partially includes) that could help, but since it had even a negative effect in recent versions of ssh, it has been disabled. You may play with the "HPNDisabled" flag and the "HPNBufferSize" value of ssh client and server.
