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

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

 



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



[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