PfSense hardware for home router - OpenVPN performance
-
Nice found!
Your's definitely a great achievement. I also have a PIA connection at moment (swedish server), but I had never exceed the theoretical maximum speed. On what PIA server are you connected? -
Interesting. There's nothing wrong with using compression. Speedtests data should probably be non-compressible to test the actual available bandwidth though. But it shows how much it can help if what you're transferring is compressible.
Steve
-
I don't see any point in enabling compression on the modern internet. The majority of data is either encrypted (thus incompressible) or already compressed (like streaming video). So outside of benchmarks it basically never gets used, but it always adds a bit of CPU overhead.
-
I guess it all depends on what your expected traffic is. Yeah if you're mostly using https and netflx then maybe not worth it. I've never actually tried to measure the overhead introduced though.
Steve
-
I guess it all depends on what your expected traffic is. Yeah if you're mostly using https and netflx then maybe not worth it. I've never actually tried to measure the overhead introduced though.
If the bulk of your traffic isn't encrypted or already compressed, then you've got a very, very unusual traffic profile. If someone's transferring huge quantities of uncompressed text over http, then sure, they should enable link compression.
-
To do a OpenVPN speed test I find that downloading a incompressible BIN or zip or … from a server(s) on the net gives better consistent results. Just search something like "download test bin zip file".
Something like: https://www.thinkbroadband.com/download
And use the download url`s in this program: http://www.nirsoft.net/utils/download_speed_tester.htmlI don't see any point in enabling compression on the modern internet
Indeed, according to the manual it adds at least 1 byte/packet for lzo + the needed processing power, for lz4 I don`t know.
-
Nice found!
Your's definitely a great achievement. I also have a PIA connection at moment (swedish server), but I had never exceed the theoretical maximum speed. On what PIA server are you connected?I use the nl.privateinternetaccess.com server, but I think it's just about selecting one near you. I'll try the Swedish one some day :)
-
Nice found!
Your's definitely a great achievement. I also have a PIA connection at moment (swedish server), but I had never exceed the theoretical maximum speed. On what PIA server are you connected?I use the nl.privateinternetaccess.com server, but I think it's just about selecting one near you. I'll try the Swedish one some day :)
I do use that one because I spend most of the year in Sweden ;).
Staying myself much closer to the Copenhagen servers I tried that connection, but performance was not as good as expected.
I'll take a look on nl servers too. Thanks! -
I guess it all depends on what your expected traffic is. Yeah if you're mostly using https and netflx then maybe not worth it. I've never actually tried to measure the overhead introduced though.
If the bulk of your traffic isn't encrypted or already compressed, then you've got a very, very unusual traffic profile. If someone's transferring huge quantities of uncompressed text over http, then sure, they should enable link compression.
This assumes you're just using the connection to do normal browsing and internet usage, i.e., an OpenVPN Client. What about the OpenVPN server. Where I connect to my home or work network from afar, often with a sub-optimal connection and transfer all kinds of files and data (much of it un-encrypted) from my home network to my laptop. This is where LZOv2 is useful.
-
why not use adaptive compression and let OVPN to decide when to use it or not ?
-
no real reason when it comes to actual day to day usage you would notice.
-
I guess it all depends on what your expected traffic is. Yeah if you're mostly using https and netflx then maybe not worth it. I've never actually tried to measure the overhead introduced though.
If the bulk of your traffic isn't encrypted or already compressed, then you've got a very, very unusual traffic profile. If someone's transferring huge quantities of uncompressed text over http, then sure, they should enable link compression.
This assumes you're just using the connection to do normal browsing and internet usage, i.e., an OpenVPN Client. What about the OpenVPN server. Where I connect to my home or work network from afar, often with a sub-optimal connection and transfer all kinds of files and data (much of it un-encrypted) from my home network to my laptop. This is where LZOv2 is useful.
I can't even think of what connections on my home network would consist of very much uncompressed data by volume. Video is compressed, pictures are compressed, documents are compressed. There'd be some uncompressed html & source code, but that would be such a small fraction of traffic as to be negligible. Again, if you really do have an overwhelming workload of uncompressed data then sure it makes sense to compress it. (Although I'd look at doing that somewhere else than the edge in the VPN client, personally–by spreading out the compression work to other places you'll be doing less in the single threaded bottlenecked openvpn process.) But for most people that's not the case, and the compression is just adding overhead with no real benefit.
-
@ecfx:
why not use adaptive compression and let OVPN to decide when to use it or not ?
So the way that works is to compress everything, then look at it, decide whether the compression ratio is good enough, stop compressing for a bit if not, then repeat that cycle. All of which happens inside the single openvpn process that doesn't scale particularly well. The only reason to bother with that is if you expect that it'll be useful at least some of the time. A few years ago I'd typically see at least 60% of traffic on an internet link be HTTP, with plain text making up a good portion of that. Now it's more common to see 60+% HTTPS by volume (not compressible) and most of the remaining HTTP is either protocol compressed or consists of images or other incompressible data. At any rate, it's not really a matter of guessing: the openvpn client status log can tell you the compression ratio you're actually getting. :)
-
The reason for this is that the Flash based speedtest.net tool does not account for LZO compression, which is built into the OpenVPN protocol.
did you try beta.speedtest.net I believe that doesn't use flash.
I have i3-7350K and I tried disabling compression and it didn't seem to make a difference, I am able to hit around 700mbs to 800mbs. Maybe i'm not disabling it correctly.
-
Yeah we aren't talking about any noticeable difference with compression on or off. That's why pretty much everyone turns out on. You won't notice the difference if you turn it off.
-
Hi guys, new to the pfSense world :)
I got a j3355b-itx coming in the mail this weekend, which I will be mainly using as VPN server for remote access.
From what I have seen, these speeds are as OpenVPN clients. Has anyone done any speed test as OpenVPN serer for remote access?
My current router tops at around 30Mbps (as vpn server), I'm hoping to achieve at least 150Mbps using the j3355b on gigabit connection.
-
There is no significant difference between client and server modes for OpenVPN. There may be a difference between encrypting and decrypting but that depends of which direction the majority of your traffic is going. It too though is not something I've seen as significant. You should be able to push 100Mbps+ with that I would expect. Let us know your results.
Steve
-
-
Hi guys, new to the pfSense world :)
I got a j3355b-itx coming in the mail this weekend, which I will be mainly using as VPN server for remote access.
From what I have seen, these speeds are as OpenVPN clients. Has anyone done any speed test as OpenVPN serer for remote access?
My current router tops at around 30Mbps (as vpn server), I'm hoping to achieve at least 150Mbps using the j3355b on gigabit connection.
From opening post:
Intel Celeron J3355 2x2GHz -TDP 10W -CPU Mark 1333 -Single Thread 884
3200/10,9 = 293 Mbps OpenVPN performance (estimate) -
From opening post:
Intel Celeron J3355 2x2GHz -TDP 10W -CPU Mark 1333 -Single Thread 884
3200/10,9 = 293 Mbps OpenVPN performance (estimate)Waiting for the chassis to arrive so I can set mine up and upgrade… IMHO for the price it's pretty impressive performance.
