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? > > 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. > > >> What was the alternative setup that was getting line rate from > this > >> VPN? Was it the same VM host, and guest kernel? > > > > It was the legit Palo Alto Global Protect linux client... > > 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? > > - 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? Dan, do you have a test GP server hack along the lines of my original http://david.woodhou.se/server.c ? What would it take to knock something up like that (with ESP support, perhaps even using the kernel's ESP on the server side) for testing? I could throw up a couple of EC2 instances and we could do performance testing between those directly....
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
