Re: [EXTERNAL] Re: What throughput is reasonable?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 :)

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
openconnect-devel mailing list
openconnect-devel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/openconnect-devel

[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux