|
|
|
|
|
by rklaehn
3 days ago
|
|
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. |
|