Hello,
recently, I've come across this test comparing OpenVPN vs. SSH tunnelling:
http://blog.backslasher.net/ssh-openvpn-tunneling.html
so natutally, I guess it would be interesting to perform similar test cases in a Kronosnet - OpenVPN duel so that the expectations are set for "VPN on steroids" and perhaps the limitations are identified if the results are too far from "on par".
(Just saying, not doing, I wouldn't go too far in tweaking kronosnet for the best results possible, I'm afraid).
On 12/15/2017 9:22 PM, Jan Pokorný wrote:
Hello,
recently, I've come across this test comparing OpenVPN vs. SSH tunnelling:
http://blog.backslasher.net/ssh-openvpn-tunneling.html
so natutally, I guess it would be interesting to perform similar test cases in a Kronosnet - OpenVPN duel so that the expectations are set for "VPN on steroids" and perhaps the limitations are identified if the results are too far from "on par".
(Just saying, not doing, I wouldn't go too far in tweaking kronosnet for the best results possible, I'm afraid).
That´s an interesting idea to expand in a spreadsheet or something.
Both implementations have pro and cons for sure and some of them are fairly well known already.
It will make sense to have this done once we rewrite kronosnetd and there is more than one user (corosync) for knet. Right now, with only one use case it´s somewhat irrelevant. knet can´t yet compete on the generic VPN use case (even tho libknet could for some areas).
Fabio
On 16/12/17 06:26 +0100, Fabio M. Di Nitto wrote:
On 12/15/2017 9:22 PM, Jan Pokorný wrote:
recently, I've come across this test comparing OpenVPN vs. SSH tunnelling:
http://blog.backslasher.net/ssh-openvpn-tunneling.html
so natutally, I guess it would be interesting to perform similar test cases in a Kronosnet - OpenVPN duel so that the expectations are set for "VPN on steroids" and perhaps the limitations are identified if the results are too far from "on par".
(Just saying, not doing, I wouldn't go too far in tweaking kronosnet for the best results possible, I'm afraid).
That´s an interesting idea to expand in a spreadsheet or something.
Both implementations have pro and cons for sure and some of them are fairly well known already.
It will make sense to have this done once we rewrite kronosnetd and there is more than one user (corosync) for knet. Right now, with only one use case it´s somewhat irrelevant. knet can´t yet compete on the generic VPN use case (even tho libknet could for some areas).
In the light of the recent KAISER/KPTI Intel et al. affair, it might also be very interesting to see the actual impact on Kronosnet on Linux.
For instance[1]:
The worst we have seen is a roughly 30% regression on a loopback networking test that did a ton of syscalls and context switches.
which allegedly comes quite close as a user/kernel space mix.
Other impact exploring examples include PostreSQL[2], for example.
[1] https://lwn.net/Articles/738997/ [2] https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbkxe%40alap...
-
Fabio M. Di Nitto -
Jan Pokorný