marten-seemann
commented
6 years ago Hi @chmike,
thanks for sharing your measurements results! First of all I'm happy to hear that you're getting close to the TCP performance. There are certain conditions under which quic-go performs significantly worse than TCP currently. I'm not sure if increasing the udp mem variable will improve the performance, please let us know if there's anything that works for you, this information would be very helpful for us.
From my own measurements, I think there's an issue with our congestion controller or with our loss recovery (or probably a combination of both). This is definitely something we will have to optimize in the future. We already have a couple of issues to track those (linking #302 and #790 here, although there's not much useful info to be found there), but I didn't have enough to look at this in detail.
I measured the throughput to send a 65MB file using quic from a lab in Mexico to a server in OVH France.
The RTT is 240ms and the network bandwidth is 8Mbit/s. Until 7Mbit/s I only lose ~1% of packets. At 8Mbit/s I lose 20%. This was measured with iPerf.
I implemented a simple basic file sending program and I can adjust the window size. I get at best 2,88 Mbit/s which is very close to what I get with TCP. Growing the window size has no effect. I was hoping I would get a better performance.
The udp mem variable has the value net.ipv4.udp_mem = 190257. Should I grow it ? Are there other system variable that could affect the performance of quic ?