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.ch}
