Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
∞ take a peek at our legendary cryptostorm_is twitter feed if you're into that kind of thing ∞
Ξ we're rolling out voodoo network security across cryptostorm - big things happening, indeed! Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit GitHub Ξ

cryptostorm: zero tolerance policy implemented

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!
User avatar

Topic Author
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

cryptostorm: zero tolerance policy implemented

Postby cryptostorm_team » Mon Feb 17, 2014 5:18 pm

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!

{direct link: zero.cryptostorm.org}
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: support@cryptostorm.is
live chat support: #cryptostorm

User avatar

spotshot
Posts: 131
Joined: Sun Feb 10, 2013 11:23 pm

Re: cryptostorm: zero tolerance policy implemented

Postby spotshot » Tue Feb 18, 2014 12:58 am

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.


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

User avatar

ABISprotocol
Posts: 36
Joined: Fri Feb 14, 2014 6:53 am

Re: cryptostorm: zero tolerance policy implemented

Postby ABISprotocol » Tue Feb 18, 2014 1:12 am

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.

<eom>
ABISprotocol ~ https://keybase.io/odinn
PGP 0x6c70abf8a7486f02
http://abis.io

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: cryptostorm: zero tolerance policy implemented

Postby Pattern_Juggled » Tue Feb 18, 2014 10:55 am

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...
PerfMon_cryptostorm.png

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. :-)
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

spotshot
Posts: 131
Joined: Sun Feb 10, 2013 11:23 pm

Re: cryptostorm: zero tolerance policy implemented

Postby spotshot » Fri Feb 21, 2014 9:18 am

sigdkiqf.jpg
sigdkiqf.jpg (24.5 KiB) Viewed 30046 times


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.


User avatar

spotshot
Posts: 131
Joined: Sun Feb 10, 2013 11:23 pm

Re: cryptostorm: zero tolerance policy implemented

Postby spotshot » Fri Feb 21, 2014 5:11 pm

normal connection is 50mb up and down.


cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

Re: cryptostorm: zero tolerance policy implemented

Postby cryptostorm_ops » Fri Feb 21, 2014 6:20 pm

spotshot wrote:
sigdkiqf.jpg


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.

User avatar

spotshot
Posts: 131
Joined: Sun Feb 10, 2013 11:23 pm

Re: cryptostorm: zero tolerance policy implemented

Postby spotshot » Fri Feb 21, 2014 7:28 pm

USA 192.96.201.85

download cryptostorm_prng.csdn, speed jumped between 514KB and 185KB and took 73seconds

User avatar

parityboy
Site Admin
Posts: 1079
Joined: Wed Feb 05, 2014 3:47 am

Re: cryptostorm: zero tolerance policy implemented

Postby parityboy » Fri Feb 21, 2014 9:56 pm

@PJ

This is clearly a problem - not a happy box on any level.


When you say box, you mean bare metal or a VM?



polarissucks01
Posts: 13
Joined: Tue Jan 21, 2014 8:25 am

Re: cryptostorm: zero tolerance policy implemented

Postby polarissucks01 » Fri Feb 28, 2014 3:43 pm

Only getting about 2 megabits on Montreal right now. Usually can get 4-4.5. No packet loss really. Weird. Support sees no issues. I'm going to try USA tomorrow.


aph
Posts: 8
Joined: Mon Feb 23, 2015 3:04 pm

Re: cryptostorm: zero tolerance policy implemented

Postby aph » Mon Feb 23, 2015 7:13 pm

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.

User avatar

privangle
Posts: 93
Joined: Thu Apr 25, 2013 5:57 am

Re: cryptostorm: zero tolerance policy implemented

Postby privangle » Tue Feb 24, 2015 11:02 am

I tried the mega link to load the testfile cryptostorm_prng.csdn, but the link does not work for me.

With wget I get a "not found" message. Did you remove the testfile ?

I did a speed test here before I found this discussion.

Indeed I experience big differences of download speed depending on the choice of the exit node, so I'm glad to read that you are working on performance.

User avatar

bricky149
Posts: 22
Joined: Tue Jan 06, 2015 8:16 pm

Re: cryptostorm: zero tolerance policy implemented

Postby bricky149 » Mon Mar 02, 2015 7:38 pm

The maximum file transfer speed I can get connected to any node is around 4.7MB/s. I am on a 52D/3U connection with a theoretical maximum of around 6.5MB/s.


turbz
Posts: 13
Joined: Sat Jun 06, 2015 5:16 pm

Re: cryptostorm: zero tolerance policy implemented

Postby turbz » Sat Jun 06, 2015 5:37 pm

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.

User avatar

parityboy
Site Admin
Posts: 1079
Joined: Wed Feb 05, 2014 3:47 am

Re: cryptostorm: zero tolerance policy implemented

Postby parityboy » Mon Jun 08, 2015 3:36 am

@turbz

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.


turbz
Posts: 13
Joined: Sat Jun 06, 2015 5:16 pm

Re: cryptostorm: zero tolerance policy implemented

Postby turbz » Mon Jun 08, 2015 1:33 pm

@parityboy

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.

User avatar

parityboy
Site Admin
Posts: 1079
Joined: Wed Feb 05, 2014 3:47 am

Re: cryptostorm: zero tolerance policy implemented

Postby parityboy » Mon Jun 08, 2015 3:29 pm

@turbz

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.

EDIT

OK, so I've opened a speed test thread here. Please contribute. :)


Guest

Re: cryptostorm: zero tolerance policy implemented

Postby Guest » Tue Jun 09, 2015 10:38 am

May I ask if you are from Germany?
Because I have a sudden speed drop since a week or two as well and I guess it has to do with some German ISPs traffic shaping vpn down.

I have a friend in the netherlands and he can use cryptostorm to full speed of his 100Mbit/s downstream connection.


turbz
Posts: 13
Joined: Sat Jun 06, 2015 5:16 pm

Re: cryptostorm: zero tolerance policy implemented

Postby turbz » Tue Jun 09, 2015 12:52 pm

No I'm not from Germany.

@parityboy
Thanks, I shall do the speed tests later today when I get back home. The other vpn provider was Airvpn.


turbz
Posts: 13
Joined: Sat Jun 06, 2015 5:16 pm

Re: cryptostorm: zero tolerance policy implemented

Postby turbz » Tue Jun 16, 2015 5:33 pm

Hi, just wondering if there's any progess happening?

User avatar

marzametal
Posts: 500
Joined: Mon Aug 05, 2013 11:39 am

Re: cryptostorm: zero tolerance policy implemented

Postby marzametal » Wed Jun 17, 2015 5:31 am

Also, still waiting on the game-changer information...


turbz
Posts: 13
Joined: Sat Jun 06, 2015 5:16 pm

Re: cryptostorm: zero tolerance policy implemented

Postby turbz » Wed Jun 24, 2015 11:25 am

Two weeks later, still no progress?


Return to “cryptostorm in-depth: announcements, how it works, what it is”

Who is online

Users browsing this forum: No registered users and 6 guests

Login