Thanks Lonnie. Yep I suspected it wouldn't be an issue but certainly
interesting info.
Seems like its pretty much based on resource usage which we are continually
monitoring. The traffic over the VPN's is very low as its voice only.
I have plenty of RAM available so no problems there.
Regards
Michael Knill
On 8/9/21, 12:27 am, "Lonnie Abelbeck" <li...@lonnie.abelbeck.com> wrote:
Hi Michael,
Good question ... I did a did a little research.
Two things come to mind, the WireGuard CPU usage per traffic and RAM usage
per peer.
WireGuard CPU usage per traffic:
-------------------------------
WireGuard uses the ChaCha20 stream cypher, while very fast just in
software, it can take advantage of common CPU features (in order of
performance) [1]
--
CPU flags: ssse3 avx2 avx512f avx512vl
--
As a test I would suggest using 'iperf3' across a WireGuard tunnel and
using 'htop' to monitor the total CPU usage across all cores. Granted not all
the CPU usage will be WireGuard, but it gives you a feel for the overall
performance.
Example:
Linode VM 1GB RAM
1-core of AMD EPYC 7601 32-Core Processor @ 2200 MHz
CPU flags: ssse3 avx2
WireGuard: iperf3 approx. 10% CPU usage for 100 Mbps traffic
BTW, If you can subtract the iperf3 CPU usage from above you would get an
even better answer.
Example:
Bare metal 4GB RAM
4-core Intel Core i3-6100U @ 2300 MHz
CPU flags: ssse3 avx2
WireGuard: 6% CPU usage for 100 Mbps traffic
WireGuard RAM usage per peer:
----------------------------
In February of 2021, Jason Donenfeld (WireGuard author) made a change
"queueing: get rid of per-peer ring buffers". [2]
Quoting Jason:
"Having two ring buffers per-peer means that every peer results in two
massive ring allocations. On an 8-core x86_64 machine, this commit reduces the
per-peer allocation from 18,688 bytes to 1,856 bytes, which is an 90%
reduction. Ninety percent! With some single-machine deployments approaching
500,000 peers, we're talking about a reduction from 7 gigs of memory down to
700 megs of memory."
BTW, this RAM peer reduction was included in WireGuard 1.0.20210219 and
AstLinux 1.4.2.
So 400 peers is very small by comparison, and even with AstLinux 1.4.1 and
older, 400 peers uses 7.5 MB RAM (750 KB with latest) which should not be an
issue in either case.
Lonnie
[1]
https://git.zx2c4.com/wireguard-linux-compat/tree/src/crypto/zinc/chacha20/chacha20-x86_64.pl?id=635aa0b75f54eddbcb29fda282d05db4b66f803c
[2]
https://git.zx2c4.com/wireguard-linux-compat/commit/?id=635aa0b75f54eddbcb29fda282d05db4b66f803c
> On Sep 6, 2021, at 5:53 PM, Michael Knill
<michael.kn...@ipcsolutions.com.au> wrote:
>
> Hi Group
>
> Just wondering what you would consider is the maximum number of clients
for a Wireguard interface that you would feel comfortable with assuming you
have enough resources to support the traffic?
> Im looking at connecting up to 400 remote peers.
>
> Regards
>
> Michael Knill
> Managing Director
_______________________________________________
Astlinux-users mailing list
Astlinux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
pay...@krisk.org.
_______________________________________________
Astlinux-users mailing list
Astlinux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
pay...@krisk.org.
