My conversation and conclusion

[bnrrteterstnjrsj45 0]

Best option for lightwightness of good protocol among present, of course, Wireguard. OpenVPN too much bottlenessic and tight , yet bulky.

Another remark - of course, the service are doing 'saving' overall throughput of servers, it never reaching their peaks, which I myself didn't like. Sounds, this can be much more liberal and users experiences true power of speed of servers and nodes.


 

[OpenSourcerer 1359]

I have no idea what you wrote in the second part, but…
 

On 11/10/2022 at 1:18 PM, bnrrteterstnjrsj45 said:

Best option for lightwightness of good protocol among present, of course, Wireguard. OpenVPN too much bottlenessic and tight , yet bulky.

Can you provide some numbers, pointers or whatever to support such a claim? If it's lines of code you refer to as "bulky", know that it doesn't matter at all.

Imagine a robot with the coded-in ability to cook, shop for ingredients and do cleaning tasks. There's code for all that, increasing "line count". And you need to configure it just right to execute these tasks in a satisfactory manner. But does that mean the robot is slower?
The other robot in the league can only cook, and it does so better than the one above. However, there is no code for going shopping: If it can't find an ingredient to work with, it… stops working. Does that mean the robot is better?

Now let's ask the question: Who do you think is best? If you can point your finger at either one robot, that's just expressing your specific requirement: Most times you'd need a robot with the most features, and in specific cases a cooking specialization is in order. Same goes for OpenVPN and Wireguard: You need the flexibility of OpenVPN to provide you with a multitude of options. And if you find that one specific UDP port with one specific cipher config suits you best, go ahead and use that specialization.

[bnrrteterstnjrsj45 0]

On 11/14/2022 at 4:46 AM, OpenSourcerer said:

I have no idea what you wrote in the second part, but…
 

Can you provide some numbers, pointers or whatever to support such a claim? If it's lines of code you refer to as "bulky", know that it doesn't matter at all.

Imagine a robot with the coded-in ability to cook, shop for ingredients and do cleaning tasks. There's code for all that, increasing "line count". And you need to configure it just right to execute these tasks in a satisfactory manner. But does that mean the robot is slower?
The other robot in the league can only cook, and it does so better than the one above. However, there is no code for going shopping: If it can't find an ingredient to work with, it… stops working. Does that mean the robot is better?

Now let's ask the question: Who do you think is best? If you can point your finger at either one robot, that's just expressing your specific requirement: Most times you'd need a robot with the most features, and in specific cases a cooking specialization is in order. Same goes for OpenVPN and Wireguard: You need the flexibility of OpenVPN to provide you with a multitude of options. And if you find that one specific UDP port with one specific cipher config suits you best, go ahead and use that specialization.

Wireguard are beatiful, still the best in speed and lightness. One thing - it stuttering in simpleTV app which I use on Win11 for watching thousands channels. And there are no any settings in Eddie, say, for changing mtu for Wireguard, so on.

Anyway, I've done some edits in OpenVPN directives. Now OpenVPN tangibly better, I can say even huge better, but settings differencies are pretty trivial.

https://prnt.sc/sR5LUog7iTil
https://prnt.sc/vk9ETb9FebAX

Some weird behavior going on with "Norway" servers, Eddie become unresponsive and you need even kill Eddie with Task Manager. While swedish servers non-problematic at all. I saw, maybe, norwegian provider are M47, GB?
 

[OpenSourcerer 1359]

TCP-NODELAY only works with TCP, hence the name, so setting it when using UDP is nonsensical.
--mode server does not make sense as well because you're trying to connect to a server, not listen on a port for client connections.
The one setting that makes it work for you is most probably tun-mtu, if it's not the server you chose which happens to work better than others.
I wonder where you copied these…

Also be advised that the notation in OpenVPN configs is without -- as shown in the list right of your custom directives. Unsure whether it works with them. Check the log for details.

[bnrrteterstnjrsj45 0]

5 hours ago, OpenSourcerer said:

TCP-NODELAY only works with TCP, hence the name, so setting it when using UDP is nonsensical.
--mode server does not make sense as well because you're trying to connect to a server, not listen on a port for client connections.
The one setting that makes it work for you is most probably tun-mtu, if it's not the server you chose which happens to work better than others.
I wonder where you copied these…

Also be advised that the notation in OpenVPN configs is without -- as shown in the list right of your custom directives. Unsure whether it works with them. Check the log for details.

Yeah, I know, just leaving it for appropriate TCP-port when using on. Thanks a lot for great feedback.