On Thu, 2019-04-04 at 22:28 +0300, Daniel Lenski wrote: > Taking a step back here… > > You and David have already resolved the issue with packets being > dropped at a high rate, so *what else* could be left that's plausibly > limiting the throughput of the VPN? It's vaguely possible that OpenConnect is sending too-large packets which get fragmented in transit, thus taking a lot more time. Although I thought we eliminated that. It's also possible that OpenConnect is *sometimes* but not consistently keeping the sendq full, which is what my last request was about. > The send-q results from netstat are kind of interesting: it looks > like there's some fluctuation where the queue drops to zero, but most > of the time it stays maxed out. Right, but that's back to testing with NFS and I'd like to see the results with UDP netperf. When the sendq was empty, the recvq was which high. I'm still aware that our packet handling is bursty and will always handling incoming packets before outgoing (on both tun and udp). Tony, can you try experimenting with the -Q option that sets the maximum internal queue length? It's 10 by default; try 100 and try lower values like 2 or 5. It does only affect packets received from the tun device; we don't ratelimit UDP input (on the basis that those are *already* in buffers and there's no sane way to throttle those while leaving packets on the tun sendq will make them visible to TCP). > Can you try to isolate the difference and eliminate other variables > by creating a VM, and then doing the samr tests back-to-back with the > official client vs. OpenConnect? Right, that's what I was trying to ask for in my last mail. > - Does netstat show similar results in terms of queue size on both? > - Is the route to the other host exactly the same with both? > - Is the VPN interface MTU the same with both?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
