We did an initial PoC on the latest RHEL, but we're restricted with what we can use in reality due to interoperability requirements with the client's baseline and tools. -----Original Message----- From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos@xxxxxxxxx] Sent: Sunday, March 17, 2019 7:45 AM To: Phillips, Tony; David Woodhouse Cc: openconnect-devel@xxxxxxxxxxxxxxxxxxx Subject: RE: [EXTERNAL] Re: What throughput is reasonable? David, Could it be we set a smaller snd or recv buffer to reduce latency in openconnect? In ocserv we have something configurable for that. BTW Tony, have you tried a more recent rhel7? On March 14, 2019 8:13:25 PM UTC, "Phillips, Tony" <tonyphillips@xxxxxx> wrote: >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. -- Sent from my mobile. Please excuse my brevity. _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
