WG Server test with flowcache bypass

[RMerlin]

I'm not done backporting Asus' flow cache bypass yet (only server part is done, client is more complicated because of having to port from VPNFusion -> VPN Director), but this is the performance the WG server is able to hit now, with the client running on a Windows laptop:

Microsoft OneDrive

1drv.ms

This is more like it.

 

[maxbraketorque]

Nice. Are you warming to WG, even if based only on performance alone?

 

[RMerlin]

Nice. Are you warming to WG, even if based only on performance alone?

Not for what most people use their VPN for, no. It's still incredibly obscure to troubleshoot.

 

[S.claus]

If only something similar was possible for Cake still great progress. Well done

 

[capncybo]

@RMerlin OMG Eric... sometimes I don't think we appreciate you enough. This news certainly has exceeded my expectations. Thanks AGAIN!!!

 

[RMerlin]

@RMerlin OMG Eric... sometimes I don't think we appreciate you enough. This news certainly has exceeded my expectations. Thanks AGAIN!!!

All thanks should go to Asus or Broadcom (not sure which of them implemented the bypass). I'm just backporting it ahead of the next GPL release which probably won't be until February.

I'm not sure either what kind of performance will be provided from Client mode, it may be different.

 

[capncybo]

All thanks should go to Asus or Broadcom (not sure which of them implemented the bypass). I'm just backporting it ahead of the next GPL release which probably won't be until February.

I'm not sure either what kind of performance will be provided from Client mode, it may be different.

Well there you go... being all humble & answering my next questions in advance, I appreciate BOTH

 

[JGrana]

Not for what most people use their VPN for, no. It's still incredibly obscure to troubleshoot.

Not when you have @Martineau and @ZebMcKayhan helping ;-)

 

[RMerlin]

And the client results:

C:\Users\rmerl\Desktop\iperf3>iperf3 -c 10.8.0.1
Connecting to host 10.8.0.1, port 5201
[  4] local 192.168.50.8 port 10344 connected to 10.8.0.1 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  47.0 MBytes   393 Mbits/sec
[  4]   1.00-2.00   sec  50.4 MBytes   422 Mbits/sec
[  4]   2.00-3.00   sec  49.2 MBytes   414 Mbits/sec
[  4]   3.00-4.00   sec  49.9 MBytes   418 Mbits/sec
[  4]   4.00-5.00   sec  50.4 MBytes   423 Mbits/sec
[  4]   5.00-6.00   sec  50.1 MBytes   421 Mbits/sec
[  4]   6.00-7.00   sec  48.1 MBytes   403 Mbits/sec
[  4]   7.00-8.00   sec  49.1 MBytes   413 Mbits/sec
[  4]   8.00-9.00   sec  50.0 MBytes   419 Mbits/sec
[  4]   9.00-10.00  sec  49.4 MBytes   414 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec   494 MBytes   414 Mbits/sec                  sender
[  4]   0.00-10.00  sec   494 MBytes   414 Mbits/sec                  receiver

Probably on par with what was experienced before, the main difference being any client NOT redirected through the tunnel will still be able to use full line speed (i.e. in my case, outside clients were still able to reach full GIgabit, only the laptop redirected through the tunnel was dropping at 350-375 Mbps).

These tests were also done within a LAN, so if you factor Internet latency, throughput may be slightly lower as well.

 

[supe]

If only something similar was possible for Cake still great progress. Well done

This would be great, as on the AX86U even WLAN to LAN gets slowed down by QOS aside from adaptive

 

[vicosphi]

Wow thank you @RMerlin I was just about to post this question, as to whether enabling Wireguard still disables flow cache. So if this is ported successfully, then Wireguard client will essentially work while retaining all hardware acceleration features like NAT, FC etc.?

 

[RMerlin]

So if this is ported successfully, then Wireguard client will essentially work while retaining all hardware acceleration features like NAT, FC etc.?

Yes, tho still don't expect WG throughput anywhere close to a desktop CPU.

This would be great, as on the AX86U even WLAN to LAN gets slowed down by QOS aside from adaptive

Cake applies to the entire LAN, therefore the entire LAN would need to bypass NAT acceleration, which would provide the exact same result as disabling NAT acceleration.

Flow cache bypass doesn't magically make WireGuard NAT accelerated. It just allows clients/servers that use WireGuard to be excluded from NAT acceleration without having to disable it for all clients that do not go through WireGuard.

 

[supe]

Yes, tho still don't expect WG throughput anywhere close to a desktop CPU.


Cake applies to the entire LAN, therefore the entire LAN would need to bypass NAT acceleration, which would provide the exact same result as disabling NAT acceleration.

Flow cache bypass doesn't magically make WireGuard NAT accelerated. It just allows clients/servers that use WireGuard to be excluded from NAT acceleration without having to disable it for all clients that do not go through WireGuard.

I see, I thought NAT acceleration was for LAN to WAN and vise-versa. I didn't know NAT was used so heavily even within local LAN to LAN or LAN to WLAN (wireless)

 

[RMerlin]

I didn't know NAT was used so heavily even within local LAN to LAN or LAN to WLAN (wireless)

It`s not. LAN/LAN traffic is only switched, and has nothing to do with Cake, which is used for WAN traffic.

 

[capncybo]

@supe IMO after RMerlin implements flowcache bypass, ditching CAKE & switching to FlexQOS may be a better option for those on asymmetrical ISP packages (with speeds less than 500Mbps). The only downside is the additional requirement of a USB-Stick or USB-Drive.

 

[dave14305]

The only downside is the additional requirement of a USB-Stick or USB-Drive.

There is no such requirement.

 

[capncybo]

There is no such requirement.

Even better & thanks for the correction. As @dave14305 would know best ;-)

 

[Morris]

@supe IMO after RMerlin implements flowcache bypass, ditching CAKE & switching to FlexQOS may be a better option for those on asymmetrical ISP packages (with speeds less than 500Mbps). The only downside is the additional requirement of a USB-Stick or USB-Drive.

Why would this be better?

 

[supe]

It`s not. LAN/LAN traffic is only switched, and has nothing to do with Cake, which is used for WAN traffic.

Oh ok, so its a long standing bug then with the AX86U. I've reported this a long time now but i guess no one uses Cake QOS on the AX86U and have a NAS.

 

[supe]

@supe IMO after RMerlin implements flowcache bypass, ditching CAKE & switching to FlexQOS may be a better option for those on asymmetrical ISP packages (with speeds less than 500Mbps). The only downside is the additional requirement of a USB-Stick or USB-Drive.

I know that's an option but I prefer the simplicity of cake, that works fine from a QOS standpoint, it's just the on the AX86U it kills my throughput to the LAN attached NAS as well.

Anyway this is slightly off topic, thanks for the clarification @RMerlin