Go-msquic: A new QUIC/HTTP3 library for Go
1–10 of 27 posts
Re: Go-msquic: A new QUIC/HTTP3 library for Go
#2msquic 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!
Re: Go-msquic: A new QUIC/HTTP3 library for Go
#3msquic 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 seems extremely high especially given how much people complain about the number of copies which, by this metric, would only cost ~7% per extra full copy.
Re: Go-msquic: A new QUIC/HTTP3 library for Go
#4msquic 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…
Network throughput and memory throughput are quite different.
Re: Go-msquic: A new QUIC/HTTP3 library for Go
#5> CGO_ENABLED=1
It's not Go then
Re: Go-msquic: A new QUIC/HTTP3 library for Go
#6> CGO_ENABLED=1 It's not Go then
To be fair, the first line in the README.md says
go-msquic is a Go wrapper for the Microsoft's QUIC library
Re: Go-msquic: A new QUIC/HTTP3 library for Go
#7Earlier 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…
Network throughput and memory throughput are quite different.
I assume their network protocol benchmark meant to show how fast their protocol implementation is relative to others is not being bottlenecked on their network bandwidth because that would be positively idiotic.
Given the machine the benchmarks are running on has a 50 Gbps NIC, that would be double stupid since their bottleneck would then need to be the production side not producing enough data to show how fast their implementation is or bad network configuration doing the same.
And that all assumes they are not bypassing the NIC entirely since they are benchmarking the protocol implementation so the source of packets is largely irrelevant except for making sure they are not still in the cache after the producer synthesizes them.
Beyond that we look to memory bandwidth as a fundamental limiting factor on data shuffling from packets to the protocol client to attempt to bound the theoretical maximum throughput so we can see how far off a protocol implementation is from the theoretical maximum.
Re: Go-msquic: A new QUIC/HTTP3 library for Go
#8msquic 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…
> 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 a number of mystical parameters.
Re: Go-msquic: A new QUIC/HTTP3 library for Go
#9Earlier 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…
> 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.