I think we do very well with devices devices with limited bandwidth and changing connections. We are able to saturate a 1 GiB link from a normal desktop PC or good phone, but have some work to do to saturate a 10 GiB link with a single process.
We don't have a comparison benchmark, but we are fast enough that we are not the limiting factor for many use cases.
In many cases the performance bottleneck is the interface to the kernel to send and receive UDP packets. Our QUIC implementation is using all available tricks to make this as fast as possible. For example on OSX we use the sendmsg_x syscall to send multiple UDP packets in one syscall. On Linux we use GRO/GSO and recvmmsg to send/receive as many packets as possible.
But to be completely honest, in some cases TCP is still faster for raw throughput on server class hardware. Decades of optimisation have gone into TCP. But QUIC/UDP is quickly catching up. All the major cloud vendors bet heavily on QUIC/UDP and are optimizing it.
Since we just do p2p QUIC we benefit directly from all improvements in this area.
> I might have assumed io_uring would be the high throughput kernel interface for Linux.
We might do an io_uring based linux only implementation at some point. For now we do care about performance very much, but also want to have a single code base for all supported architectures and platforms.
We do support a lot out of the box, which is hard enough as is with a small team. And while io_uring is a bit better than the current sendmsg with GSO / recvmmsg with GRO setup, it isn't orders of magnitude.
> Can iroh run on a proxy server which forwards requests to backends that don't integrate with iroh directly?
We have a tool called dumbpipe that has options to forward local tcp services over an iroh pipe. Something like global netcat.
And there are plenty of tools that do something similar for specific services, e.g. there is iroh-ssh.
> What is the CPU overhead at link saturating speeds?
We don't have exact measurements, but CPU is not the bottleneck usually.
