very low throughput on Mac OS X

[David Woodhouse]

On Wed, 2016-08-17 at 09:26 -0700, Tom Rodriguez wrote:
> > I’ve been using open connect on Mac OS X and noticed that I’m
> getting much worse throughput than the same setup running on linux on
> a local virtual machine.  Almost an order of magnitude worse.  I’ve
> googled for help on the issue but without any luck, so here I am.  

Under Linux I'd be pointing you at the profiling tools so you can see
precisely where the *system* is spending its time.

For OS X I am unfamiliar with any such tools. One thing which comes to
mind is the different tun devices. We'll be using utun on OS X these
days by default... does it get better if you install the Tun/Tap driver
and use that instead? There's plenty of scope for screwing performance
up in the user/kernel interface...


> I’ve tried a few different command line options and adjusting the MTU
> but without luck.  Are there any known issues concerning this?  I do
> get a lot of "Failed to write incoming packet: No buffer space
> available” on the mac but it didn’t seem like enough to explain the
> low throughput. 

That's on receiving a packet from the VPN, and feeding it to the kernel
through (presumably) the utun interface. Which tends to support my
first supposition above...

Note that we *drop* the packet when that happens. See the code at
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tun.c#l551
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/mainloop.c#l95

So... the tun interface's queue is full and it stops accepting packets
from us. We *drop* them, and that's going to screw your TCP connections
up quite a lot.

In an ideal world, the poll() system call would let us know when the
tun is writeable again, and we'd start shovelling packets then. In
Linux that doesn't work so as the comments note, we don't bother with
that. But perhaps we should, for OS X? You'd make os_write_tun()
actually return -EAGAIN, and make mainlop.c react accordingly by
calling monitor_write_fd() on the tun fd and only ever trying to write
to it when it's... well, writeable.

And we'd still need a hack for Linux so that we don't just busy-wait
trying to write the same packet over and over again until it's
accepted. But first check if the utun interface really *does* support
poll() for writeability at all, perhaps...

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20160818/a44dfaf4/attachment.bin>