7 ms·

Very impressive performance: > While performance is quite good right now (~7.5Gbps TX on my small test box), not a lot of effort has yet been spent on optimizi

by Panino 5y ago

Very impressive performance: > While performance is quite good right now (~7.5Gbps TX on my small test box), not a lot of effort has yet been spent on optimizing it > Jonathan Tooker reported to me that, on his system with an Intel AC9560 WiFi card, he gets ~600Mbps without WireGuard, ~600Mbps with wireguard-go/Wintun over Ethernet, ~95Mbps with wireguard-go/Wintun over WiFi, and ~600Mbps with WireGuardNT over WiFi. Congratulations to Simon and Jason! Very happy WireGuard user here.

brian_herman 5y ago
Yes, I am gonna reinstall wireguard on my raspberry pi again. This is amazing news. And I will try and getting my windows server ryzen pc to be a router so I can benchmark all four configs.
- eptcyka 5y ago
  If you're running a recent enough kernel, it's technically already there, maybe without the userspace tools.
- alexellisuk 5y ago
  Have you checked out some of the other options for remote access to your Raspberry Pi, like Tailscale (no affiliation) and inlets https://johansiebens.dev/posts/2020/11/quake-iii-arena-k3s-and-a-raspberry-pi/ https://johansiebens.dev/posts/2020/11/quake-iii-arena-k3s-a...?
jve 5y ago
People always compare bandwidth which is important. Has anyone done any comparisons how latency is affected between various VPN implementations?
- zekica 5y ago
  Wireguard adds fixed latency as it doesn't do any buffering except for the one packet it is currently working on. The only exception is initial handshake which adds 1rtt for the first packet being sent.
  - deadmutex 5y ago
    > adds fixed latency I don't know much about WireGuard, but generally speaking large fixed latency during one step can lead to huge variance in end to end latency due to queuing.
    - monocasa 5y ago
      That one piece is for initialization. I'm not sure about wireguard, but I've typically seen that abstractions of ethernet stacks like VPNs will either throw away packets to be sent before initialization is complete, or will structurally simply not allow anything to be queued at that point in the first place (so like if it's a user space implementation, use type safety somehow so you can't even call send_packet() until it's done with init). In those modes the fixed latency of init doesn't cause buffer bloat issues.
- Bayart 5y ago
  Add jitter to the list. Consistency is probably more important for end-user perception than average latency.

by Panino 5y ago

brian_herman 5y ago

Yes, I am gonna reinstall wireguard on my raspberry pi again. This is amazing news. And I will try and getting my windows server ryzen pc to be a router so I can benchmark all four configs.

eptcyka 5y ago
If you're running a recent enough kernel, it's technically already there, maybe without the userspace tools.
alexellisuk 5y ago
Have you checked out some of the other options for remote access to your Raspberry Pi, like Tailscale (no affiliation) and inlets https://johansiebens.dev/posts/2020/11/quake-iii-arena-k3s-and-a-raspberry-pi/ https://johansiebens.dev/posts/2020/11/quake-iii-arena-k3s-a...?

jve 5y ago

People always compare bandwidth which is important. Has anyone done any comparisons how latency is affected between various VPN implementations?

zekica 5y ago
Wireguard adds fixed latency as it doesn't do any buffering except for the one packet it is currently working on. The only exception is initial handshake which adds 1rtt for the first packet being sent.
- deadmutex 5y ago
  > adds fixed latency I don't know much about WireGuard, but generally speaking large fixed latency during one step can lead to huge variance in end to end latency due to queuing.
  - monocasa 5y ago
    That one piece is for initialization. I'm not sure about wireguard, but I've typically seen that abstractions of ethernet stacks like VPNs will either throw away packets to be sent before initialization is complete, or will structurally simply not allow anything to be queued at that point in the first place (so like if it's a user space implementation, use type safety somehow so you can't even call send_packet() until it's done with init). In those modes the fixed latency of init doesn't cause buffer bloat issues.
Bayart 5y ago
Add jitter to the list. Consistency is probably more important for end-user perception than average latency.