Re: Low capped TCP network speeds over the Internet

[mlelstv%serpens.de@localhost (Michael van Elst)]

z411%omaera.org@localhost (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.