Proton VPN created a feature that accelerates your VPN by 400%

[fUnDaMeNtAl_knobhead]

1 minute ago, J-from-Nucleon said:

True,

Proton VPN (I'm using it temporariliy while trying to setup my wireguard server), uses like 200-400MiB of RAM while wireguard uses like less that 50MiB....

But you get less location and no GUI right???

 

[Lightwreather]

Just now, linux fanboy said:

But you get less location and no GUI right???

 

Less location yes,

Gui, There is one for macOS, and for windows iirc

[fUnDaMeNtAl_knobhead]

7 minutes ago, J-from-Nucleon said:

True,

Proton VPN (I'm using it temporariliy while trying to setup my wireguard server), uses like 200-400MiB of RAM while wireguard uses like less that 50MiB....

Do you run it locally or on a vps ?

[Lightwreather]

43 minutes ago, linux fanboy said:

Do you run it locally or on a vps ?

VPS
Using azure, 'cause it's free for students like me and it doesn't require cc for students

 

[fUnDaMeNtAl_knobhead]

1 minute ago, J-from-Nucleon said:

VPS
Using azure, 'cause it's free for students like me and it doesn't require cc for students

 

Won't it be slower because it isn't bare metal?

[Lightwreather]

Just now, linux fanboy said:

Won't it be slower because it isn't bare metal?

I honestly don't know, but my speeds have generally been good (imo), apart from the sometimes high ping

[fUnDaMeNtAl_knobhead]

Why not just use commercial vpn some of them have ram disk servers but vps doesn't.

[williamcll]

How good is this compared to gaming accelerators like WTFast?

[leadeater]

5 hours ago, Kisai said:

so if the VPN adds 180ms then that means it's likely travelling 500 miles back and forth first

That sort of distance is only about 11ms not 180ms. Round trip on one of our site links that is a little over 300 miles is 9ms.

 

5 hours ago, Kisai said:

Let's be honest though, 200ms (nagle algorithm) is what all software is designed around

Nagle doesn't add 200ms or make application experience effective 200ms, I think you may have misinterpreted some information you have read. SMB on local networks just wouldn't work, it would have crippling performance. All operating systems have nagle enabled by default and you can disable it but it's really not recommended to, because it's almost always worse. If you want to improve performance on a real time application the TCP_NODELAY session flag can be set, which most applications already do, which is much better than trying to disable nagle which subjects you to all the problems for why it was created and implemented. Basically don't turn it off it's not actually a good idea or will benefit you.

 

Also insufficient buffers cause higher latency not lower. Buffers have such a negligible impact to latency, even on local networks, it's best to increase them to maximum sizes allowed. This is of course not always best but it's only going to matter on local networks with ultra low latency for applications that use very frequent small message sizes.

 

If you really want a high throughput low latency VPN then you really need a UDP IPSec tunnel (IKEv2) rather than SSLVPN or SSTP however the latter two are much easier to work with and traverse through firewalls than most IPSec based VPNs. I don't know much about WireGuard but it's the current hot in thing that's supposed to be "the best".

 

My advice is to only use VPNs for georestriction reasons and nothing else, unless it's your corporate remote access VPN but totally different story. You are best served by relying on application SSL encryption and not tunneling all your traffic through a single point. Also use DNS over HTTPS. There are betters ways to "increase privacy" than using a VPN which I would not be on the side of argument of that it does at all.

[leadeater]

3 hours ago, linux fanboy said:

Won't it be slower because it isn't bare metal?

 

3 hours ago, J-from-Nucleon said:

I honestly don't know, but my speeds have generally been good (imo), apart from the sometimes high ping

Baremetal is a security marketing point, it actually has little to do with latency or performance overall unless the hosting platform is particularly bad or you're (they) are paying bottom rate for the cheapest low priority instances.

 

When VPN companies are saying baremetal they are pointing to that other server instances cannot exploit potential vulnerabilities to get outside the bounds of their VM instance because there isn't multiple VMs running on the hardware (from any random customer). It's more about trust and control than performance.

[Sauron]

20 hours ago, Moonzy said:

enabling protonVPN actually lowers my ping to certain servers from 220ms to 180ms, so i guess there's that

Sounds like an issue with the server you're contacting limiting traffic towards your region...

20 hours ago, linux fanboy said:

We cannot increase the speed of light or bring New Zealand closer to Europe, but VPN Accelerator addresses the issue by breaking up the 600 ms path into shorter paths (for example, two 300 ms paths). Much faster goodput is possible on each of the shorter paths, resulting in higher combined performance over the entire path. 

I... disagree with this concept...

 

in most cases where you care about ping you care about direct responses to specific requests, splitting up the path doesn't do anything useful in that case. Plus it adds whatever processing overhead is generated at the halfway point.

 

Also that "400%" claim is most definitely some incredibly contrived and cherry picked metric that won't mean anything in day to day use.

[Moonzy]

1 minute ago, Sauron said:

Sounds like an issue with the server you're contacting limiting traffic towards your region...

Eh, I could connect to the same country with VPN and it still is lower

I guess my ISP routing just sucks lol

[Lightwreather]

5 hours ago, linux fanboy said:

Why not just use commercial vpn some of them have ram disk servers but vps doesn't.

Listen, I have no money to spend on a decent commercial vpn, and all free VPNs are either terrible, sell your data (which I'm not about) or lack in features.

So, an azure vm that I can spin for no direct cost to me, has greater worth (not to mention, it's completely for my use only) and is generally faster (compared to free VPNs), seeing as it is microsoft

[Kisai]

2 hours ago, leadeater said:

That sort of distance is only about 11ms not 180ms. Round trip on one of our site links that is a little over 300 miles is 9ms.

 

Trust me when I say this. Speedtest is not a good representation of anything but your local speed. Anything farther than 9 time zones had 200ms. Games that connect between East and West coast America have 180ms.

 

You can't tell me that that everyone is 8 time zones away from each other. DBD is based out of Montreal, but the closest server is in Oregon, which is much closer, and usually reports 80ms, or 807km away. Just for reference, speedtest reports this as 37ms.

 

Quote

Nagle doesn't add 200ms or make application experience effective 200ms, I think you may have misinterpreted some information you have read.

Nah, Nagle was intended to for Dial-up and Dial-up alone. Everyone who plays MMO games turns Nagle off because games amazingly do not, and it vastly improves responsiveness. Even that DBD game above is improved by having Nagle turned off. The test for that however was a game that would be 13 years old now, where a specific skill in the game was locked exactly to the nagle algorithm's delays, and turning Nagle off let you spam the skill instantly. The servers were in LA and I had 20ms latency to that location.

 

https://www.speedguide.net/articles/gaming-tweaks-5812

 

The basic point of reference is that pretty much everything intended to increase bandwidth comes at the expense of latency due to buffering, and anything intended to reduce latency comes at the cost of reducing buffering somewhere in the process.  Nagle being just one of those. This is also a reason why you don't use your gaming rig for work.

 

Given how much better bandwidth is now compared to even 5 years ago, let alone 15, yet somehow nagle still manages to be the bane of every online game. If you don't turn it off, you're in for a bad time, every time, especially when it's the first thing everyone recommends to do when they notice their game isn't as smooth as everyone elses, if you don't do it, you're putting yourself at a disadvantage since everyone who's been playing online games since XP has. 

 

Half the excuses for using a VPN to "improve" gaming performance are often just snake oil, and at best it's only usable to side-step poor routing by the ISP as a last-resort anyway. Using it for privacy, doesn't really protect you from much of anything, and if anything it punches a hole through your own security provided by the router you already have.

 

To be honest, I'm not even sure why anyone in North America would even bother with these VPN programs if they weren't up to something they needed to hide. Enterprise VPN's are a whole other animal entirely, intended for security, but definitely not privacy.

 

Quote

 

Also insufficient buffers cause higher latency not lower. Buffers have such a negligible impact to latency, even on local networks, it's best to increase them to maximum sizes allowed. This is of course not always best but it's only going to matter on local networks with ultra low latency for applications that use very frequent small message sizes.

https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/

 

[leadeater]

1 hour ago, Kisai said:

Trust me when I say this. Speedtest is not a good representation of anything but your local speed. Anything farther than 9 time zones had 200ms. Games that connect between East and West coast America have 180ms.

Why would you think I used speed test to measure the latency of a private 100Gb datacenter link? 500 miles simply does not equate to 180ms, that sort of latency over that distance is due to everything but the distance.

 

1 hour ago, Kisai said:

Nah, Nagle was intended to for Dial-up and Dial-up alone. Everyone who plays MMO games turns Nagle off because games amazingly do not, and it vastly improves responsiveness. Even that DBD game above is improved by having Nagle turned off. The test for that however was a game that would be 13 years old now, where a specific skill in the game was locked exactly to the nagle algorithm's delays, and turning Nagle off let you spam the skill instantly. The servers were in LA and I had 20ms latency to that location.

And all of this it completely and utterly wrong and those saying to do this do not understand it at all.

 

Here is the source of this information, our at least one of the sources, and in this paper you can see that nagle is not the issue.

https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.31.8823&rep=rep1&type=pdf

 

Nagle is not for dial-up only, why would every OS today still have it enabled (and applied to local network traffic) if it's only purpose was for low bandwidth links like dial-up. Simply because it's not.

 

The proper way to mitigate being affected by nagle, if you actually are and the application is not disabling TCP Delayed ACK, is to set TcpAckFrequency registry setting to 1.

 

But again both nagle and delayed ACK have reasons to exist and can/will negatively impact network performance if you disable them. Turn off nagle all you like the other end of the connection has it on so you aren't achieving much, disabling delayed ACK now that actually does affect both ends of a connection.

 

1 hour ago, Kisai said:

https://www.speedguide.net/articles/gaming-tweaks-5812

Never have I seen a collection of such band information in my life. What's sad is there is at least one or two actually worthwhile things to try in there but it's let down by the other 99% of the bad. And at no point have they provided any evidence, actual data, to show what any of their "advice" does.

 

1 hour ago, Kisai said:

https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/

Also wrong, but hey what would I know 

[leadeater]

12 minutes ago, James Evens said:

Latency and bandwidth are totally independent things. One is a measurement for how long it takes to get the response. The other one just how much data in a given time can be moved.

For example a SD card in a pneumatic pipe has a incredibly high bandwidth but latency is in the minutes to hour range. Compare that to a single glass fibre: significantly lower bandwidth but latency in the nanosecond range.

No they are not independent things, have you never seen this formula before?

 

 

How much data you can move in a given time is directly impacted by latency. This of course does not take in to account other more complicated factors like multi sessions and data streams and is also only for TCP traffic not UDP but even for UDP latency still has a direct impact on throughput.

 

Bandwidth is only a theoretical maximum whereas throughput is what you are or can achieve and that is the result of almost entirely latency.  Sure I did say achievable bandwidth rather than throughput but it's pretty clear in what I was qualifying by that statement.

 

Quote

The difference between bandwidth and throughput isn’t necessarily simple. They tell you two different things about the data in your network, but they’re closely related. You can think of bandwidth as a tube and data throughput as sand. If you have a large tube, you can pour more sand through it at a faster rate. Conversely, if you try to put a lot of sand through a small tube, it will go very slowly.

 

In short, throughput and bandwidth are two different processes with two different goals both contributing to the speed of a network. Data throughput meaning is a practical measure of actual packet delivery while bandwidth is a theoretical measure of packet delivery. Throughput is often a more important indicator of network performance than bandwidth because it will tell you if your network is literally slow or just hypothetically slow.

https://www.dnsstuff.com/network-throughput-bandwidth

[leadeater]

4 minutes ago, James Evens said:

Sure to some degree they are related but at the scale you look at the are basically degrees of freedom

It's more than some degree, it's literally part of networking 101 and also TCP 101. Learning the difference between bandwidth and throughput and why is quite important as it's foundational knowledge to understanding what is going on and why.

 

Latency is and will always be why you'll never achieve the same throughput to and endpoint with greater latency than one with lower latency, putting aside exceeding maximum link bandwidth.

 

8 minutes ago, James Evens said:

In practice it comes all down to the protocol and how you implement the application on it.

Correct and it's the very formula I just gave you that plays in to why they do many of the things they do. It's why for example Globus (research data transfer) implements multiple data streams because without it you'll never achieve 100Gbps throughput across the country without doing that due to latency.

 

Not everything can be a UDP data stream with also no sent data verification.

[Awesome84]

On 9/6/2021 at 10:12 AM, Stahlmann said:

Are they trying to achieve negative latency?

 

C'mon, we had enough brands shooting themselves in the foot because of ridiculous claims.

Especially Stadia

[Kisai]

6 hours ago, leadeater said:

And all of this it completely and utterly wrong and those saying to do this do not understand it at all.

 

Here is the source of this information, our at least one of the sources, and in this paper you can see that nagle is not the issue.

https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.31.8823&rep=rep1&type=pdf

 

From the article

Quote

oad to routers and switches. In the early 1980s, terminal (telnet) traffic constituted a large amount of the traffic on the Internet. Often a client would send a sequence of short packets, each containing a single keystroke, to the server. At the time, these short packets placed a significant load on Internet, especially given the relatively slow links, routers, and servers.

 

 

6 hours ago, leadeater said:

Nagle is not for dial-up only, why would every OS today still have it enabled (and applied to local network traffic) if it's only purpose was for low bandwidth links like dial-up. Simply because it's not.

Because it's the expected default behavior.

 

6 hours ago, leadeater said:

The proper way to mitigate being affected by nagle, if you actually are and the application is not disabling TCP Delayed ACK, is to set TcpAckFrequency registry setting to 1.

Which is ALSO done.

6 hours ago, leadeater said:

But again both nagle and delayed ACK have reasons to exist and can/will negatively impact network performance if you disable them. Turn off nagle all you like the other end of the connection has it on so you aren't achieving much, disabling delayed ACK now that actually does affect both ends of a connection.

https://bugs.freedesktop.org/show_bug.cgi?id=17868

 

You'll see that disabling Nagle and Disabling Delayed ACK come up in the same conversations, often as being one and the same (including Wikipedia.)

6 hours ago, leadeater said:

Never have I seen a collection of such band information in my life. What's sad is there is at least one or two actually worthwhile things to try in there but it's let down by the other 99% of the bad. And at no point have they provided any evidence, actual data, to show what any of their "advice" does.

That's just what happens when a collection of various pieces of information get bundled up as optimizations without knowing why you'd turn something on or off.

 

Like the latest "latency fixer" is turning off mouse acceleration, despite most games using common game engines like Unreal already using raw inputs. The previous was turning off vsync. All of these have "lag" or "latency" in their name, but have absolutely nothing to do with each other and no bearing on the network unless the game has garbage netcode inside the input thread, which a lot of games do in fact have, or we wouldn't be having this argument.

6 hours ago, leadeater said:

Also wrong, but hey what would I know 

Again, this is literately common knowledge for PC gamers.

That is the "optimal" settings in TCP Optimizer. Note what's under Nagle's algorithm.

How many people read the docs? 

https://www.speedguide.net/articles/tcp-optimizer-4-documentation-windows-7-8-10-2012-5821

 

Quote

Gaming Tweak - Disable Nagle's algorithm

Nagle's algorithm is designed to allow several small packets to be combined together into a single, larger packet for more efficient transmissions. While this improves throughput efficiency and reduces TCP/IP header overhead, it also briefly delays transmission of small packets. Disabling "nagling" can help reduce latency/ping in some games. Keep in mind that disabling Nagle's algorithm may also have some negative effect on file transfers. Nagle's algorithm is enabled in Windows by default.

TcpAckFrequency: 1 for gaming and Wi-FI (disables nagling), small values over 2 for pure throughput.

TcpNoDelay: 1 for gaming (disables nagling), 0 to enable nagling

TcpDelAckTicks: 0 for gaming (disabled), 1-6 denotes 100-600ms. Setting to 1 reduces nagling effect (default is 2=200ms).

 

You'd think that if there was any detrimental effects from the settings that mattered, the "optimal" settings would be different. The only setting I've ever seen have a detrimental effect on ANYTHING was changing the congestion control setting, which made Mass Effect's servers unreachable.

 

[Lurick]

44 minutes ago, Kisai said:

 

 

 

 

Where are you getting those from because every NIC in my PC shows n/a as OPTIMAL and Default, which means enabled:

 

Additionally the recommended setting is to leave it set to n/a and you have to do custom to disable it.

[HenrySalayne]

News or an ad?

[fUnDaMeNtAl_knobhead]

1 hour ago, HenrySalayne said:

News or an ad?

News?

[leadeater]

8 hours ago, Kisai said:

Again, this is literately common knowledge for PC gamers.

I am both a PC gamer, former competitive COD4 player, and a Systems Engineer with a lot of networking and firewalls background. I can see through all the  "gaming optimization" for what it is because I do actually know what all the settings are, how they work and why they exist.

 

Common knowledge is not the same thing as correct knowledge 

 

8 hours ago, Kisai said:

You'd think that if there was any detrimental effects from the settings that mattered, the "optimal" settings would be different. The only setting I've ever seen have a detrimental effect on ANYTHING was changing the congestion control setting, which made Mass Effect's servers unreachable.

It does and you can measure it, and the impact is even more important on DOCSIS than it is on say FTTH/GPON. By not buffering and combining in to fewer larger packets you can easily overburden signal conversion processing, additionally because each packet needs processes that has a latency overhead which can be higher than the small delay that nagel adds and then the signal processing happens far less resulting in lower effective latency at the application layer.

 

The other problem like I mentioned in my other post is you can turn off nagel all you like but it's still on at the server end and they will also be doing Receive Side Coalescing as well so you're putting a bunch of work on your network and increasing packet processing required and it's just getting undone at the other end. Packet processes is not free and it's ideal to do as little of it as possible, and offload as much as possible.

 

This why very good and accurate data collection is required to measure the application network characteristics and performance to verify the settings changes being applied are actually doing anything and if so what it's actually doing. Without that how do you know what you are doing is doing anything or is making it better, if you think it does then you'll believe and feel like it does where the data may not back that at all, but I guess what's most important is if you think and feel it helps your game play then that is actually enough regardless if it actually is.

 

So I'm not suggesting going and undoing things you have done, this is more just an educational FYI as to what appears to be some misconceptions about a few things.

[RejZoR]

I think the point of ProtonVPN's accelerator is not to magically improve a perfect connection, it's meant to accelerate connections with bunch of hops by bypassing them with own route. CloudFlare does a similar thing with 1.1.1.1. acceleration.

[fUnDaMeNtAl_knobhead]

19 minutes ago, RejZoR said:

I think the point of ProtonVPN's accelerator is not to magically improve a perfect connection, it's meant to accelerate connections with bunch of hops by bypassing them with own route. CloudFlare does a similar thing with 1.1.1.1. acceleration.

Then go to the blog post and read it for yourself to see if your theory is correct