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>
