<div dir="ltr">Hi!, iperf results!<br><div><br></div><div>Peers: server 10.11.12.1 and client 10.11.12.2 <br><br>UDP test<br><br></div><div>100MB transfer (with a size similar to the theoretical raspberry pi fast ethernet limit (100mbps)<br><br></div><div><br>pi@raspberrypi:~ $ iperf -c 10.11.12.2 -u -p 12345 -t 30 -b 100M<br>------------------------------------------------------------<br>Client connecting to 10.11.12.2, UDP port 12345<br>Sending 1470 byte datagrams<br>UDP buffer size:  160 KByte (default)<br>------------------------------------------------------------<br>[  3] local 10.11.12.3 port 47707 connected with 10.11.12.2 port 12345<br>[ ID] Interval       Transfer     Bandwidth<br>[  3]  0.0-30.0 sec   278 MBytes  77.8 Mbits/sec<br>[  3] Sent 198395 datagrams<br>[  3] Server Report:<br>[  3]  0.0-30.3 sec  6.30 MBytes  1.75 Mbits/sec  11.417 ms 193896/198393 (98%)<br>pi@raspberrypi:~ $<br><br><br></div><div>WITH the NEW SNAPSHOT (20170531)<br><br>pi@raspberrypi:~ $ iperf -c 10.11.12.2 -u -t 30 -b 100M<br>------------------------------------------------------------<br>Client connecting to 10.11.12.2, UDP port 5001<br>Sending 1470 byte datagrams<br>UDP buffer size:  160 KByte (default)<br>------------------------------------------------------------<br>[  3] local 10.11.12.3 port 59246 connected with 10.11.12.2 port 5001<br>[ ID] Interval       Transfer     Bandwidth<br>[  3]  0.0-30.0 sec   275 MBytes  77.0 Mbits/sec<br>[  3] Sent 196350 datagrams<br>[  3] Server Report:<br>[  3]  0.0-30.2 sec  6.67 MBytes  1.85 Mbits/sec  10.785 ms 191590/196347 (98%)<br>[  3]  0.0-30.2 sec  1 datagrams received out-of-order<br><br><br></div><div>Results are what i expected, both rpi3 hitting the limit of the fast ethernet. I'm gonna test it with two routers (Netgear X4S nighthawk, with  ARM neon and Gigabit ethernet interface). <br></div><div><br></div><div>Best!<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 3, 2017 at 3:31 AM, Jason A. Donenfeld <span dir="ltr"><<a href="mailto:Jason@zx2c4.com" target="_blank">Jason@zx2c4.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, Jun 3, 2017 at 12:47 AM, Le Sandie <<a href="mailto:lesandie@gmail.com">lesandie@gmail.com</a>> wrote:<br>
> I have tested the WireGuard-0.0.20170531 snapshot between two ARM peers (a<br>
> couple of rpi3s with the same snapshot) and it works nice. I haven't had<br>
> time to iperf but will do to check that performance raise in ARM SoCs.<br>
<br>
</span>Great, please do let me know.<br>
<span class=""><br>
><br>
> Also i tested this snapshot with one ARM peer and the other peer with a LEDE<br>
> (17.01.1) router with wireguard and the handshake goes well but no<br>
> connectivity between peers. If i downgrade the ARM peer snapshot to<br>
> WireGuard-0.0.20170421, both peers see each other with connectivity.<br>
> Probably when the openwrt/LEDE package maintainer bump up the package to the<br>
> new snapshot it will work.<br>
<br>
</span>Yes indeed there was a backwards incompatible change made. The<br>
openwrt/lede package already has been bumped, however, so just update<br>
your system.<br>
<a href="https://github.com/openwrt/packages/blob/master/net/wireguard/Makefile" rel="noreferrer" target="_blank">https://github.com/openwrt/<wbr>packages/blob/master/net/<wbr>wireguard/Makefile</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Lt. Col. Sandie</div>
</div>