Niklas - Okay cool, totally understandable. Thanks for all the insight, I'll take a look into that patch and see if we can revive the effort.
I did another round of perf testing with ProcessPriority set to high in the tinc.conf. That looks like we're getting an average of +3% across our TInc nodes. Still under 50% of the raw network bandwidth over Tinc, which was my original goal. If anyone else has ideas on settings I should try to tweak, I'm more than happy to give it a shot and retest our performance. Thanks again, Jared On Wed, May 17, 2017, at 03:10 PM, Niklas Hambüchen wrote: > On 17/05/17 21:50, Jared Ledvina wrote: > > Were you ever able to make any further > > progress on adjusting Tinc based on the investigation in > > https://github.com/gsliepen/tinc/issues/110 ? > > Hi Jared, > > No, not yet. > > I list a few ways for potential improvements in the ticket, but the one > that I suspect would do most on the type of virtualisation that > DigitalOcean does is to add a feature to the Linux kernel to sending the > data for multiple UDP packets in one syscall, as mentioned in comment > https://github.com/gsliepen/tinc/issues/110#issuecomment-201949838. > > In the last message of that Kernel code review, Alex Gartrell says > "Sounds good to me. I'll get a patch turned around soon.". I don't know > if they ever got around to it. It might be worth shooting an email to > ask! > It would be great to have that feature. > > For me personally the issue became less important, when I realised that > the syscall overhead is more specific to the DigitalOcean virtualisation > and less prominent with the virtualisation that AWS uses. > I also currently use mainly bare metal so that this issue affects me > even less. I would still love to see it fixed or if it myself (if I need > it, or I have some free time, or if I find somebody who wants me to do > it for them). > > Niklas _______________________________________________ tinc mailing list [email protected] https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
