Improving packets/sec and data rate - v1.0.24

[Jared Ledvina]

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