11–20 of 27 posts
> CGO_ENABLED=1 It's not Go then
It is mentioned & advised to use that one in the README. However if you need more perf, you might want to give a try at go-msquic.
msquic is one of the most performant QUIC protocol library out there. go-msquic is a wrapper around msquic so you can use it inside your Go project. https://github.com/noboruma/go-msquic The project is quite new, but we have seen good performance results with it so far. PRs are welcome!
Their dashboard [1] shows the library only gets ~7 Gbps on what is presumably a single core (given that it is single connection benchmark). Is that considered fast? The memory bus on that system probably pushes at least ~400 Gbps, and even a fairly simple memcpy() implementation could probably push ~100 Gbps even at standard MTU (i.e. small) sizes. So that would be ~14 copies worth of execution cost per bit. That see…
That's the reason we decided to go ahead and see how it performs within our Go lang code base.
On our setup we are seeing a 50% latency reduction compared with other implementations. Definitely worth a try if you are looking for performance.
Earlier quoted context omitted.
> Is [~7 Gbps] considered fast? With Quic, yes. I don’t have hands on experience with this lib but throughput is not the strength of quic. In fact, that’s true for untuned UDP in general. Oftentimes CPU will bottleneck without bespoke platform-specific hacks to avoid the one syscall per 1260 bytes default/portable status quo. I don’t know that bench but throughput varies wildly between environments, cross traffic and…
Do we know if that is true for whatever Google is using internally on their servers? Are they also only getting ~7 Gbps per core or are they going much faster either due to software or hardware? What are the actual exemplary implementations because ~7 Gbps per core seems really slow for an actual quality production implementation based on my read of the QUIC standard.
Not really? With a 128-core machine, that's in the ballpark of 900 Gbps; you're hitting other bottlenecks far earlier than that. And in practice, we're talking about 256 hardware threads for a dual-socket Epyc Milan server, which has been the machine-of-the-day at Google for years now. AMD server processors are so big these days that you could spend a quarter of your compute on QUIC without blinking an eye, be able to serve 450 Gbps on paper per machine, and ultimately hit bottlenecks because disk I/O isn't able to feed the NIC that fast for YouTube serving.
One of the biggest things holding QUIC performance back is a chicken-and-egg problem: vendors don't want to implement NIC offload because there aren't enough companies that want it, and companies don't want to use QUIC because it represents such a big performance drop relative to TCP's decades of tuning with the Linux kernel (in part because of the lack of NIC offload).
Earlier quoted context omitted.
Their dashboard [1] shows the library only gets ~7 Gbps on what is presumably a single core (given that it is single connection benchmark). Is that considered fast? The memory bus on that system probably pushes at least ~400 Gbps, and even a fairly simple memcpy() implementation could probably push ~100 Gbps even at standard MTU (i.e. small) sizes. So that would be ~14 copies worth of execution cost per bit. That see…
Most of the benchmarks comparing msquic with other libraries are showing it on top. That's the reason we decided to go ahead and see how it performs within our Go lang code base. On our setup we are seeing a 50% latency reduction compared with other implementations. Definitely worth a try if you are looking for performance.
msquic is one of the most performant QUIC protocol library out there. go-msquic is a wrapper around msquic so you can use it inside your Go project. https://github.com/noboruma/go-msquic The project is quite new, but we have seen good performance results with it so far. PRs are welcome!
Their dashboard [1] shows the library only gets ~7 Gbps on what is presumably a single core (given that it is single connection benchmark). Is that considered fast? The memory bus on that system probably pushes at least ~400 Gbps, and even a fairly simple memcpy() implementation could probably push ~100 Gbps even at standard MTU (i.e. small) sizes. So that would be ~14 copies worth of execution cost per bit. That see…
msquic is one of the most performant QUIC protocol library out there. go-msquic is a wrapper around msquic so you can use it inside your Go project. https://github.com/noboruma/go-msquic The project is quite new, but we have seen good performance results with it so far. PRs are welcome!
Their dashboard [1] shows the library only gets ~7 Gbps on what is presumably a single core (given that it is single connection benchmark). Is that considered fast? The memory bus on that system probably pushes at least ~400 Gbps, and even a fairly simple memcpy() implementation could probably push ~100 Gbps even at standard MTU (i.e. small) sizes. So that would be ~14 copies worth of execution cost per bit. That see…
Whether it's "considered fast" is better answered by simply comparing the practical numbers, like in that dashboard, rather than supposition. This kind of question is more aimed at trying to find out "how fast could it possibly be".
msquic is one of the most performant QUIC protocol library out there. go-msquic is a wrapper around msquic so you can use it inside your Go project. https://github.com/noboruma/go-msquic The project is quite new, but we have seen good performance results with it so far. PRs are welcome!
Their dashboard [1] shows the library only gets ~7 Gbps on what is presumably a single core (given that it is single connection benchmark). Is that considered fast? The memory bus on that system probably pushes at least ~400 Gbps, and even a fairly simple memcpy() implementation could probably push ~100 Gbps even at standard MTU (i.e. small) sizes. So that would be ~14 copies worth of execution cost per bit. That see…
I would guess that it's not a single core benchmark and that's the speed of the overall multi-threaded system.
> Is that considered fast?
You can squeeze out around 5GB/s/core with current fastest standard tls1.3 algorithm (AES128GCM). 10+GB/s is possible with aegis variants that are somewhat popular as an extension to TLS libs.
Earlier quoted context omitted.
Their dashboard [1] shows the library only gets ~7 Gbps on what is presumably a single core (given that it is single connection benchmark). Is that considered fast? The memory bus on that system probably pushes at least ~400 Gbps, and even a fairly simple memcpy() implementation could probably push ~100 Gbps even at standard MTU (i.e. small) sizes. So that would be ~14 copies worth of execution cost per bit. That see…
> what is presumably a single core I would guess that it's not a single core benchmark and that's the speed of the overall multi-threaded system. > Is that considered fast? You can squeeze out around 5GB/s/core with current fastest standard tls1.3 algorithm (AES128GCM). 10+GB/s is possible with aegis variants that are somewhat popular as an extension to TLS libs.
Also, it would be silly to bottleneck your protocol implementation benchmark on encryption that would be shared amongst implementations because that does not highlight your overhead advantages. In addition, the benchmarking RFC explicitly allows for the null encryption case in benchmarking for exactly that reason.
Earlier quoted context omitted.
Do we know if that is true for whatever Google is using internally on their servers? Are they also only getting ~7 Gbps per core or are they going much faster either due to software or hardware? What are the actual exemplary implementations because ~7 Gbps per core seems really slow for an actual quality production implementation based on my read of the QUIC standard.
> ~7 Gbps per core seems really slow for an actual quality production implementation Not really? With a 128-core machine , that's in the ballpark of 900 Gbps; you're hitting other bottlenecks far earlier than that. And in practice, we're talking about 256 hardware threads for a dual-socket Epyc Milan server, which has been the machine-of-the-day at Google for years now. AMD server processors are so big these days tha…
Having done the majority of a QUIC implementation myself, achieving (on the non-encryption portion) 10 Gbps (1.5x faster) seems trivial, 30 Gbps per core (4x faster) seems straightforward, and 100 Gbps per core (15x faster) looks possible.
I was looking for benchmarks of professional implementations to see the limits of the protocol, but all I see are rates in the single digit Gbps which I assumed were toy re-implementations based on my analysis of what should be possible. But apparently these are state of the art implementations so now I am trying to figure out if anybody knows the specific reasons for the performance disparity.
Earlier quoted context omitted.
> what is presumably a single core I would guess that it's not a single core benchmark and that's the speed of the overall multi-threaded system. > Is that considered fast? You can squeeze out around 5GB/s/core with current fastest standard tls1.3 algorithm (AES128GCM). 10+GB/s is possible with aegis variants that are somewhat popular as an extension to TLS libs.
5 GB/s per core would still be 40 Gbps per core, so only ~15% of their time would be spent in encryption. They spend 5x longer doing the non-encryption stuff. Also, it would be silly to bottleneck your protocol implementation benchmark on encryption that would be shared amongst implementations because that does not highlight your overhead advantages. In addition, the benchmarking RFC explicitly allows for the null en…
It would be great if benchmarks with no encryption were a thing.
There's massive overheads, and I explicitly avoided saying whether it's "fast" or not because to a lot of people serving 1000req/s seems "fast" and TLS is basically the main algorithmic complexity you'd expect from a data transfer protocol.