On Mon, 2019-04-08 at 13:47 +0000, Phillips, Tony wrote: > > Ok, you can't run GP on the real target machines... can you try > > Openconnect on the machine where you *do* have GP running? > > Well, as (lack of) luck and bad timing would have it, the evaluation > license for the GP Linux client expired last month. > > So we're not going to be able to do any additional testing against the GP client. Ah, OK. But we can still run on the same VM where it *had* been running, can't we? > > Didn't that change with my retry patch? I'd also be interested to see > > similar measurements while running netperf on the system running the GP > > client. > > As to the patches and discards, no, they increased. That was noted > back in the March 25 portion of the history. I suspect we're looking at slightly different metrics then. Yours was the overall SNMP stats, right? We should be seeing the dropped packets as drops on the tun device now, instead of dropped UDP packets. And the sending TCP stack ought theoretically to have a slightly higher chance of knowing that they're happening. Let's try again to analyse what OpenConnect is doing. Please run the netstat UDP_STREAM test with 'perf record -a', which should also capture what OpenConnect is doing. Let's confirm OpenConnect really is taking 100% cpu (in 'top') while that happens. And that OpenConnect is using AES-NI. Please use a test "server" according to the instructions I gave, which is actually a VM sitting next to the one under test. Let's identify if it's just that the software in that VM *can't* create ESP packets at the rate we need, and eliminate other factors. My own testing was in a Fedora VM, not RHEL. Trying that in the same VM hosting environment as your existing tests might also be enlightening. If Fedora works well and something in RHEL slows it down, that would also be good to know (see also 'check it's using AES-NI' above).
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
