Re: speed, CPU

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

 



Let's benchmark with netperf UDP to start with, to eliminate TCP effects and packet loss. Test with different packet sizes.

On 30 December 2019 10:48:19 GMT, Nikos Mavrogiannopoulos <n.mavrogiannopoulos@xxxxxxxxx> wrote:
It wouldn't matter benchmarking it. It will not be significantly different. From what you describe the crypto capacity of cpu is at least 10-fold what you see on the wire. So the issue is somewhere else. 

On December 30, 2019 10:08:28 AM UTC, Carles Pina i Estany <carles@xxxxxxxx> wrote:

Hi,

On Dec/30/2019, David Woodhouse wrote:
On Sat, 2019-12-28 at 22:53 +0100, Carles Pina i Estany wrote:
Hi openconnect,

I have a question regarding CPU usage, network speed and
openconnect.

I'm using openconnect from Debian (Debian package version 8.02-1)
connecting to a Cisco AnyConnect. I'm using NetworkManager but I'm
happy
to use the command line if this would help.

A few months ago we had a similar thread, and some performance
improvements went into the 8.03 release. Please could you update to
git
master and try?

on Saturday I tried with v8.05. I couldn't see any big improvement.
Since then I reverted back to use the Debian package (v8.02-1)
integrated with the NetworkManager.

There's also an experimental perfhacks branch:

http://git.infradead.org/users/dwmw2/openconnect.git/shortlog/refs/heads/perfhacks

Most of that is for ESP support, not DTLS, but the 'reuse packets
instead of free/malloc' bought us a few percent and I'd like to
eventually fix up all the buffer sizing inconsistencies and merge it
(or just move to using rings).

I'll try to test the perfhack branch today.

I see that openconnect uses about 35 to 40% of CPU (measured with
top)
in my 4 cores laptop.

When using openconnect the connection is about 5 to 8 MB/s
otherwise
more than twice this speed.

The system administrators on the other side don't seem to be aware
of
any speed limitation or throttling.

The internet connection or even the upload speed to the other side
is
higher if no OpenConnect is used.

My question is: do you know of any way to make the VPN faster?

Any experience compiling openconnect (I might try this anyway)
instead
of using the Debian precompiled version? Any parameters that could
be
used, faster cyphering, etc.?

You can try forcing it to use different ciphers with the
--dtls-ciphers
option.

I haven't succeeded forcing gnutls-cli to do benchmarks for
AES-256-CBC.
I've tried:
gnutls-cli --benchmark-ciphers --priority=PERFORMANCE
gnutls-cli --benchmark-ciphers --priority=SECURE256

--dtls-ciphers is not an option on my gnutls-cli (version 3.6.7)

Please could you set it running, then use 'perf record -a
netperf....'
to record the *full* system activity (including kernel and
openconnect)
for each of a large upload, and a large download. Use your own
existing
benchmark or workload if that's easier than netperf.

Let's see where it's actually spending the time, and what we can do
about it.

I'll do it.

Thanks!

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
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