Also of note is that when you do your tests, you’re getting CPU/bound at 100%. I never paid much attention to overall CPU until I saw your stats last week. We can’t get OC to run over maybe 35%. This may boil down to how we have vSphere configured (or VMWare in general versus AWS’s hypervisor). > On Apr 18, 2019, at 3:25 PM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > >> On Thu, 2019-04-18 at 20:06 +0000, Phillips, Tony wrote: >> David, I've gone dark for a week or two as project priorities have >> shifted and this has gone somewhat back-burner. >> >> I did want to report a new finding we made last week, though: >> >> I managed to score, for a limited amount of time, a rather >> underutilized host. The host is identical in hardware configuration >> to the one I've been on this whole time, EXCEPT that it's 10G >> attached instead of 1G attached. But we know from raw network >> iperf/netperf (with no VPN) that the network isn't the issue. >> >> Since this host is barely utilized, it's zero CPU oversubscription, >> whereas our other cluster is maybe 7-8x CPU oversubscribed. >> >> We saw that not only was the basic VPN (using the original EAGAIN- >> patched 8.02) faster by at least 20%, it was much more consistently >> faster. This hints to me that the mere act of context-switching the >> VMs around might have some play here, and more guests sharing the >> host is factoring in. > > 20% faster is still fairly appalling though, right? That would still > put you under 200Mb/s when we were after ten times that (assuming the > NIC can take it). > > But yeah, vCPU context switching, which thanks to Intel is going to > involve a full L1 cache flush amongst other things, is certainly not > going to help much. > >> It's important to note that we do NOT oversubscribed memory. >> >> Any chance that you could repeat YOUR tests on a more-densely-shared >> AWS instance, say like a t2.xlarge or c5.xlarge? > > Even c5.xlarge doesn't overcommit CPU, so doesn't have to incur quite > as much security overhead as when you're context switching between > vCPUs of different guests. > > I'll throw up a CPU-unlimited t3 (if I can remember how to do that) and > see how it performs. Obviously the CPU limiting you normally get on a > T3 is going to have its own interesting effects on throughput :) _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
