Hi, we are using Tinc in our Freifunk Network in Oldenburg for internode connections over the internet. So Tinc is running on OpenWrt 10.03 on Dlink Dir-300 Routers. We all have enough internet bandwith (1,6 MB/sec and more) but we only get a maximum speed of ~350KB/sec between two tinc nodes because then tinc uses 99% of the cpu. Is it possible to get more Speed with tinc on this machines? I think we have compression and encryption already turned off so what is using the cpu? Our Tinc configuration looks like this: --------- Name = 0014224074A7 Mode = Switch Port = 655 #PingTimeout = 30 Hostnames=yes PMTUDiscovery=yes Cipher = none Compress = 0 Digest = none IndirectData = yes ConnectTo=0021912CF309 ConnectTo=00240117B755 ConnectTo=batgw ConnectTo=0022B0967CD7 ConnectTo=0014224074A7 ---------- If there is no way to get more speed, do you know another VPN-Solution which is better concerning speed? We dont need security because the network is completely open, but we need speed. Thank you Clemens -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20100920/8506b7f1/attachment.pgp>
moin, Am Montag, 20. September 2010, 16:37:03 schrieb Clemens John:> we are using Tinc in our Freifunk Network in Oldenburg for internode > connections over the internet. So Tinc is running on OpenWrt 10.03 on Dlink > Dir-300 Routers. > We all have enough internet bandwith (1,6 MB/sec and more) but we only get > a maximum speed of ~350KB/sec between two tinc nodes because then tinc > uses 99% of the cpu.We faced the same issues on our routers. They are used as mesh-nodes in a Freifunk network, too ;)> Is it possible to get more Speed with tinc on this machines? I think we > have compression and encryption already turned off so what is using the > cpu?We tried to profile this, but it wasn?t easy to do that on the hardware, so we gave up on this :/ We also couldn?t see any difference when turning off encryption, IIRC. I remember running tinc using valgrind on my desktop and mentioned, that most time was spent with xor operations, so in the crypto part. I can?t remember many details but I concluded, that everything seems fine on the desktop. May be, you could try to reproduce this or get any better results than me. If you?re interested, I might have the data still laying around somewhere.> Our Tinc configuration looks like this: > --------- > Name = 0014224074A7 > Mode = Switch > Port = 655 > #PingTimeout = 30 > Hostnames=yes > PMTUDiscovery=yes > Cipher = none > Compress = 0 > Digest = none > IndirectData = yes > ConnectTo=0021912CF309 > ConnectTo=00240117B755 > ConnectTo=batgw > ConnectTo=0022B0967CD7 > ConnectTo=0014224074A7 > ----------Seems, you are using our scripts, if I think about it ;) or you just had the same idea to use the routers? MAC addresses as names in tinc ;) At least this seems very familiar to me.> If there is no way to get more speed, do you know another VPN-Solution > which is better concerning speed? We dont need security because the > network is completely open, but we need speed.I expect, you want to use tinc to connect several mesh-clouds using tinc over some private Internet connections. That?s exactly, what we had in mind when we decided that we want to use tinc for that. It just seemed to be _the_ tool to do this job. Please keep me posted if you make any progress. (contact me directly or just post to our ML: freifunk.luebeck AT asta.uni-luebeck.de) bye then julian PS: At the moment, our group is a little inactive, because we didn?t have much time recently. But I think, at least I will be able to discuss these issues, may be we can find a solution for this. If you want us to test something or want to know details about our setup, just ask. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20100920/0fd11db7/attachment.pgp>
That device uses the Atheros AR2317 processor which isn't exactly robust at 180Mhz. Have you considered alternative hardware? On Mon, Sep 20, 2010 at 10:37 AM, Clemens John <clemens-john at gmx.de> wrote:> Hi, > > we are using Tinc in our Freifunk Network in Oldenburg for internode > connections over the internet. So Tinc is running on OpenWrt 10.03 on Dlink > Dir-300 Routers. > We all have enough internet bandwith (1,6 MB/sec and more) but we only get > a > maximum speed of ~350KB/sec between two tinc nodes because then tinc uses > 99% > of the cpu. > > Is it possible to get more Speed with tinc on this machines? I think we > have > compression and encryption already turned off so what is using the cpu? > > Our Tinc configuration looks like this: > --------- > Name = 0014224074A7 > Mode = Switch > Port = 655 > #PingTimeout = 30 > Hostnames=yes > PMTUDiscovery=yes > Cipher = none > Compress = 0 > Digest = none > IndirectData = yes > ConnectTo=0021912CF309 > ConnectTo=00240117B755 > ConnectTo=batgw > ConnectTo=0022B0967CD7 > ConnectTo=0014224074A7 > ---------- > > If there is no way to get more speed, do you know another VPN-Solution > which > is better concerning speed? We dont need security because the network is > completely open, but we need speed. > > Thank you > Clemens > > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20100920/883be1de/attachment.htm>
On Mon, Sep 20, 2010 at 04:37:03PM +0200, Clemens John wrote:> we are using Tinc in our Freifunk Network in Oldenburg for internode > connections over the internet. So Tinc is running on OpenWrt 10.03 on Dlink > Dir-300 Routers. > We all have enough internet bandwith (1,6 MB/sec and more) but we only get a > maximum speed of ~350KB/sec between two tinc nodes because then tinc uses 99% > of the cpu. > > Is it possible to get more Speed with tinc on this machines? I think we have > compression and encryption already turned off so what is using the cpu?[...]> If there is no way to get more speed, do you know another VPN-Solution which > is better concerning speed? We dont need security because the network is > completely open, but we need speed.Are you sure you have 1.6 MB/sec both upstream and downstream? You can try other VPN software, such as OpenVPN or perhaps VDE, and see if those are faster. Maybe you can also try profiling tinc (either with valgrind's callgrind tool, or compile tinc with -pg in both CFLAGS and LDFLAGS so you can use gprof) to see where the bottleneck is. However, the Dir-300 has a MIPS processor running at 182 MHz with only 16 kB instruction and 16 kB data cache. That means it is not very fast, especially not if a packet has to go all the way to userspace to be processed by tinc and back. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20100920/379d7f61/attachment.pgp>
> We all have enough internet bandwith (1,6 MB/sec and more) but we only get a > maximum speed of ~350KB/sec between two tinc nodes because then tinc uses 99% > of the cpu.What about packets per second ? Are you sending a lot of small packets ? That could be a problem ! my 2 cents. Saverio
Am Dienstag 21 September 2010, 10:13:30 schrieb ZioPRoTo (Saverio Proto):> > We all have enough internet bandwith (1,6 MB/sec and more) but we only > > get a maximum speed of ~350KB/sec between two tinc nodes because then > > tinc uses 99% of the cpu. > > What about packets per second ? > > Are you sending a lot of small packets ? That could be a problem !I?m shure. I?m not that familar with networks. Our tinc device tap0 has an MTU of 1500 but it is in a bridge (br-mesh) wich has an MTU of 1476. Maybe you can have a look at this? -------------- root at 00240117B755:~# brctl show br-mesh bridge name bridge id STP enabled interfaces br-mesh 8000.00240117b755 yes ath0 bat0 tap0 root at 00240117B755:~# ifconfig ath0 Link encap:Ethernet HWaddr 00:24:01:17:B7:55 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:13119 errors:0 dropped:55 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:998226 (974.8 KiB) ath1 Link encap:Ethernet HWaddr 06:24:01:17:B7:55 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:701 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:163844 (160.0 KiB) br-mesh Link encap:Ethernet HWaddr 00:24:01:17:B7:55 inet6 addr: fe80::224:1ff:fe17:b755/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1476 Metric:1 RX packets:8588 errors:0 dropped:0 overruns:0 frame:0 TX packets:5705 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1058896 (1.0 MiB) TX bytes:817276 (798.1 KiB) tap0 Link encap:Ethernet HWaddr 8E:33:AE:29:5B:16 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:12472 errors:0 dropped:0 overruns:0 frame:0 TX packets:18438 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:1776840 (1.6 MiB) TX bytes:1794668 (1.7 MiB) wifi0 Link encap:UNSPEC HWaddr 00-24-01-17- B7-55-00-00-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:514267 errors:0 dropped:0 overruns:0 frame:1242 TX packets:91806 errors:1439 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:195 RX bytes:71111579 (67.8 MiB) TX bytes:9736303 (9.2 MiB) Interrupt:3 Memory:b0000000-b000ffff ------- Greetings Clemens -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20100921/cbbd518f/attachment.pgp>
> Our tinc device tap0 has an MTU of 1500 but it is in a bridge (br-mesh) wich > has an MTU of 1476. Maybe you can have a look at this?OK, maybe you have a problem with packet fragmentation and you waste a lot of CPU. Try to put the MTU of your tap device to a lower value. Make this test MTU 1280 and add the following rule to your iptables firewall: iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu this will cause new TCP connections to use segments that fit your interface MTU. Note that 1280 is not the optimal value, you can fine tune later if you see you get more speed. Saverio
Am Dienstag 21 September 2010, 13:51:26 schrieb ZioPRoTo (Saverio Proto):> > Our tinc device tap0 has an MTU of 1500 but it is in a bridge (br-mesh) > > wich has an MTU of 1476. Maybe you can have a look at this? > > OK, maybe you have a problem with packet fragmentation and you waste a > lot of CPU. > Try to put the MTU of your tap device to a lower value. > > Make this test MTU 1280 and add the following rule to your iptables > firewall: > > iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS > --clamp-mss-to-pmtu > > this will cause new TCP connections to use segments that fit your interface > MTU. > > Note that 1280 is not the optimal value, you can fine tune later if > you see you get more speed.Yeah! That gave me a performance boost of about 150K/s and tincd does not get at 99% CPU anymore. I now get a maximum of ~530K/s. I will try to evaluate this :) If you have more of such good tips I?m ofcourse interested :D Clemens -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20100921/28acccc4/attachment.pgp>
On Tue, Sep 21, 2010 at 02:49:30PM +0200, Clemens John wrote:> Am Dienstag 21 September 2010, 13:51:26 schrieb ZioPRoTo (Saverio Proto): > > OK, maybe you have a problem with packet fragmentation and you waste a > > lot of CPU. > > Try to put the MTU of your tap device to a lower value.[...]> Yeah! That gave me a performance boost of about 150K/s and tincd does not get > at 99% CPU anymore. > I now get a maximum of ~530K/s.Which version of tinc are you using? -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20100921/0125b58b/attachment.pgp>
Am Dienstag 21 September 2010, 14:56:05 schrieb Guus Sliepen:> On Tue, Sep 21, 2010 at 02:49:30PM +0200, Clemens John wrote: > > Am Dienstag 21 September 2010, 13:51:26 schrieb ZioPRoTo (Saverio Proto): > > > OK, maybe you have a problem with packet fragmentation and you waste a > > > lot of CPU. > > > Try to put the MTU of your tap device to a lower value. > > [...] > > > Yeah! That gave me a performance boost of about 150K/s and tincd does not > > get at 99% CPU anymore. > > I now get a maximum of ~530K/s. > > Which version of tinc are you using?We use Tinc 1.0.13. root at 00240117B755:~# tincd --version tinc version 1.0.13 (built Jul 23 2010 21:08:01, protocol 17) Regards Clemens -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20100921/b65e6f5d/attachment.pgp>
On Tue, Sep 21, 2010 at 7:49 AM, Clemens John <clemens-john at gmx.de> wrote:> Am Dienstag 21 September 2010, 13:51:26 schrieb ZioPRoTo (Saverio Proto):>> this will cause new TCP connections to use segments that fit your interface >> MTU.I have had this problem too! Can you do the same for UDP connections?