Hey, folks, here's some more info for you that is interesting.
The VMs on which we're trying to use Open Connect move a lot of data.
TCP stats are showing significant packets losses that are not present when openconnect isn't in the path.
Before job IP and TCP stats:
Ip:
6769930 total packets received
0 forwarded
0 incoming packets discarded
6769470 incoming packets delivered
12959167 requests sent out
441423 outgoing packets dropped <-----------
36 dropped because of missing route
1 fragments dropped after timeout
861 reassemblies required
430 packets reassembled ok
1 packet reassembles failed
430 fragments received ok
860 fragments created
Tcp:
1618 active connections openings
168 passive connection openings
57 failed connection attempts
0 connection resets received
11 connections established
3381430 segments received
8560742 segments send out
441689 segments retransmitted <-----------
3 bad segments received.
1077 resets sent
Compare to After:
Ip:
7444894 total packets received
0 forwarded
0 incoming packets discarded
7444354 incoming packets delivered
14107699 requests sent out
478311 outgoing packets dropped <-----------
36 dropped because of missing route
1 fragments dropped after timeout
1021 reassemblies required
510 packets reassembled ok
1 packet reassembles failed
510 fragments received ok
1020 fragments created
Tcp:
1700 active connections openings
179 passive connection openings
64 failed connection attempts
0 connection resets received
9 connections established
3718616 segments received
9295454 segments send out
478353 segments retransmitted <-----------
3 bad segments received.
1148 resets sent
So about 37,000 outgoing IP packets dropped.
About the same number of TCP segments retransmitted.
Segments retransmitted as a percentage of segments sent: 5%.
That's pretty destructive to a TCP flow. Incidentally, we're using NFS over TCP to do the file handling.
When the tunnel is NOT in use, the numbers drop to near 0 delta.
-----Original Message-----
From: David Woodhouse [mailto:dwmw2@xxxxxxxxxxxxx]
Sent: Tuesday, March 12, 2019 4:47 PM
To: Phillips, Tony; Nikos Mavrogiannopoulos
Cc: openconnect-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [EXTERNAL] Re: What throughput is reasonable?
On Tue, 2019-03-12 at 15:21 +0000, Phillips, Tony wrote:
> + 48.50% 0.08% lt-openconnect [kernel.vmlinux] [k] system_call_fastpath
> + 19.57% 0.10% lt-openconnect [kernel.vmlinux] [k] sys_write
> + 19.37% 0.15% lt-openconnect [kernel.vmlinux] [k] vfs_write
> + 18.22% 0.00% lt-openconnect libpthread-2.17.so [.] __write_nocancel
> + 17.74% 0.08% lt-openconnect [kernel.vmlinux] [k] do_sync_write
> + 17.67% 0.08% lt-openconnect [tun] [k] tun_chr_aio_write
> + 17.52% 0.45% lt-openconnect [tun] [k] tun_get_user
Well, that certainly seems like I've done a fair job of getting
OpenConnect's own code out of the way, and making sure it's all about
the necessary system call overhead.
It'd certainly be interesting to see what we get if we use the kernel's
ESP support. OpenConnect will dump the keys, and we should be able to
hack out its own ESP implementation and just configure the kernel
instead. Might need some experimentation to send the empty 'probe'
packets and to make OpenConnect send the switch command over the TCP
connection, but coming up with a hackish way of doing that just to test
should be simple enough.
_______________________________________________
openconnect-devel mailing list
openconnect-devel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/openconnect-devel
