cryptostorm's community forum

Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit here or GitHub Ξ
Ξ If you're looking for tutorials/guides, check out the new https://cryptostorm.is/#section6 Ξ

Looking for a bit more than customer support, and want to learn more about what cryptostorm is , what we've been announcing lately, and how the cryptostorm network makes the magic? This is a great place to start, so make yourself at home!

We're announcing a Zero Tolerance Policy... with regards to poor network performance. Which means we reject the standard assumption that using a network security service means slow, laggy, poor connectivity.

There is no technological reason for that assumption to hold true, and we've made it a top priority for our entire team that performance on-network is excellent, always. We're not there yet, and we know there's improvements we can - and must - continue to make, for cryptostorm. But performance is as much a no-compromise issue for our team as is serious cryptographic foundations and sound OpSec procedures. Slow networks don't get used, and a network that isn't used is no security whatsoever. Therefore, performance is crucial not just for a better day-to-day experience but also as a core security parameter.

Zero Tolerance for crappy network performance. It's not necessary, it's not acceptable, and it's not part of what cryptostorm exists to deliver.

We're opening this thread to centralise discussions of and reports on network performance whilst connected to cryptostorm. There's already several existing threads that discuss performance tuning in various specialised regards (links: bittorrent | kernel-level tuning parameters | NAT & port forwarding), and this thread doesn't seek to replace those. Rather, this thread is a place to post basic performance feedback an questions.

To get started, we created a test download file that can be found at this link (which points to a Mega URL; redirect is mapped from https://cryptostorm.is/testfile as well). We're using Mega for this, as they tend to do a good job running their servers - and we know they're not biased. Some of these "speed test" services... they're not always 100% reliable, let's just say that. This link won't wget as it's all pretty much served up in a http wrapper - but that's not necessarily inappropriate given real-world connection usage. We've also put up the same file on one of our administrative servers in Iceland - it's less useful for testing Icelandic cluster performance as it's geographically in the same DC - but for all other clusters, it's useful as a secondary data point. That one will wget, however, so that can be useful.

Using test files like this is most effective when doing A/B comparatives on-net/off-net as close to temporally congruent as possible. In other words, pull the file - then disconnect from cryptocloud and pull the same file again, immediately. Do this back and forth a couple times, at different times of day, and those data are starting to build up a really useful foundation for quantitative measures of network performance.

The test file - cryptostorm_prng.csdn - is 13.37 megabytes of uncompressed, highly "random" data generated via SHA512 hashing and IV procedures used by the TrueCrypt application. The suffix "csdn" (cryptostorm darknet) is non-syntactical & thus hopefully won't trigger most layers of QoS, packet shaping, traffic heuristics, and so on - a source of many problems whilst assessing network performance metrics. There's nothing "inside" it, so if you want to burn a whack of time seeking to break the ciphers, you'll probably be really disappointed if you somehow succeed. Fair warning

Ok, with that let's get the conversation going regarding speed test results, performance feedback, techniques for optimising client-side performance, and so forth!

not great, was averaging 80KB's, it stalled out around 80% and took 4min,
waiting a few minute and tried it again, second try it started out around 400KB, stalled at 70% and
finished up around 40KB took about 6minutes.

my isp speed before connecting is 50up and down,
at the moment on speedtest, montreal im getting 10up and 15 down.

download same file - averaged 1.1mb and it took about 10seconds

jumped over to filehippo and grab something approx. same size,
it averaged 250KB and took about 45second.

with utorrent, ive seen connect max out around 2500kB's, nothing to complain about there.

My own thoughts on this may or may not be relevant to the Cryptostorm items in this thread here under discussion, but I'll toss this out.

I use an ISP that I respect and appreciate due to the fact that they do respect my privacy. Not going to mention names here.

This said, based on the location and range of what the ISP can do, and the fact that it hasn't expanded into many areas effectively yet, I've been willing to accept lesser speeds while knowing that on the privacy side, things are good with them. Standard alternatives (buying internet connection from major telcos) don't work for me, given that the "privacy" practices of the major telcos (at least where I live) are just a horrible joke at best.

Thus far with the ISP I have I have never had inability to access the service, it has never discriminated as to my traffic, they refuse to implement "six strikes" (essentially, they are non-cooperative with respect to censorship requests from the copyright industry), and any activity that is logged is gone after two weeks. No logs would be better, but it strikes me that if my alternatives are to reside with providers that do terrible things to people (including, but not limited to, storing all traffic for up to five years) then I am much better off with who I am with.

spotshot wrote:with utorrent, ive seen connect max out around 2500kB's, nothing to complain about there.

I will test again later to see if I get same result

This is useful data. An extra request, and then a reminder for other folks who will be posting as well.

If possible, please do pin down the specific node IP when you are doing testing as this greatly helps isolate issues within a given cluster. If this isn't convenient, test data are still very useful... but far more so when we can then correlate down to a specific machine at a specific time of day. In reality, on a daily basis we're dealing with at least one performance issue in at least one of our datacentres somewhere in the world: an upstream switch is feeling off, or a wholesale pipe has been oversold, or a NIC is going sour, or any of a dozen things that happen between the DC and the internet at large. We're notoriously aggressive about measuring performance metrics on our nodes and "working closely" with DC staff to ensure bottlenecks are resolved ("working closely" being a nice way of saying that we're obsessively intense about this particular issue - infamously so). When we see a problem, on the Ops team, we are immediately pushing for resolution and we will pull a machine out of production pool if it's not resolved fast.

This is a daily part of the business, as there's no "perfect" datacentre out there and even really well-run DCs will have issues from time to time. So, for us, it's about redundancy, performance metrics, and close attention to operational results on a realtime basis. For all these reasons, specific IPs help tremendously. For example, we've had one machine in the Montreal cluster that's been throwing transient performance issues for several weeks. Stuff like this...

This is clearly a problem - not a happy box on any level. Members transiting this node are going to see choppy performance, inexplicable snags... totally unacceptable. This throws all sorts of red flags for us, and we're at once on the DC staff to rectify - which, in a good DC, is a collaborative process. Diagnostics are nontrivial as a result of the transient nature - we're working with the DC in question to get this machine either settled or replaced. On a personal level, I have nightmares about machines like this, quite literally. They are the bane of good performance, as they can throw a spanner in all the best engineering efforts at every OSI layer above 2. Meh.

It's an example of the ongoing, behind-the-scenes side of operations - these issues never really go away, as we've enough machines that someone's going to be sad on any given day. Our job is to ensure that's decoupled from network member experience, and to pull machines from prod pool before impact is felt.

Ok, and as spotshot correctly did please do be as careful as possible in distinguishing "little-b" bits from "big-B" Bytes. Inevitably, there's occasional confusion - but some speed testing tools report b's and some B's (most the latter, really)... whereas nearly all hardware metrics run on bits: megabits/sec, gigabits/sec, etc. Needless to say, there's an eightfold difference between the two: 8 bits to a Byte. Not everyone adheres to the big-versus-little b standard, but it's a bloody handy trick for keeping the two separate even when tired, distracted, etc.

speeds are great, download is better than other day, but would have excepted faster
download with these speeds.
not sure how this helps, but I will test again when I'm not in peak hours.

montreal 70.38.46.224

way better than other day.
tested again, different time of the day, still in peak hours, but speeds much better,
averaged approx. 150KB and 77seconds.

Thanks for doing this - it really helps.

We're in the midst of scheduling a swap-out of some suspected-buggy hardware in our Montreal infrastructure, and in my own monitoring of resources over there I still see unacceptable performance on the box in question (we suspect a bad NIC) - so it's good to see the cluster isn't entirely incapable of supporting some strong throughput even before we get this maintenance work done.

I think many users, myself included, are seeing 50mbps caps not necessarily due to the node's maximum throughput but due to the current state of OpenVPN and more so as a result of the single threaded intensive calculations necessary to transfer large amounts of data encrypted with stronger ciphers.

Perhaps a test node with 128 bit encryption would be helpful to determine that. I haven't been able to connect to cryptostorm with anything under 256 bit for both TLS and regular transport. If I set it up the OpenVPN client with the CS config files on my router it slows down to 10-15mbps, and that's on a dedicated core of high-end router.

Why is the speed on CS constantly under 5MB/s?
No matter the node or what I'm downloading, it never passes some 4.7MB/s.
My connection is "100/10mbps" and with other vpn providers I get up to 12MB/s and without anything, I get usually around 10.

It's dependent on many different factors, but let's focus on the things under your control. Is your VPN connection on your desktop or your router? If on your desktop, what's your OS? What's your CPU? What's the CPU utilisation? CS uses AES-256-CBC for encryption, which is pretty CPU intensive.

Its running on my laptop, windows 8.1, Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz which supports hardware accelerated AES and the client+openvpndaemon never go over 3%, usually staying under 2% and usually when doing torrenting, the total cpu utilization is under 10%.
And all the other hardware seems to be well under the max capacity

The other vpn I tried before cryptostorm seems to be using the same encryption and had no difficulties reaching 12mbps.

That's strange - just out of interest, who are the other VPN provider, and do they also use OpenVPN? It sounds like the node is throttled on a per-session basis, but we all know that's not true, because others have reported much higher speeds through the same nodes. Unfortunately, I can't be of much help because my connection is 8Mb/1Mb ADSL.

Actually...screw it, let's just do it anyway. I'm going to start a performance thread, just to see what people are getting. At least then we'll get some kind of picture.