Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

CrashPlan appears to upload stuff on the standard HTTPS port 443.

Is there any way to allocate it bulk QoS priority separately from all other HTTPS traffic, or am I completely stuffed?

I'm using DD-WRT.

share|improve this question
up vote 5 down vote accepted

Set the DSCP value you want via local machine policy using the process name and destination port to ensure you only tag crashplan traffic, not anything else on port 443.

I just blogged about this, including video:

EDIT : updated post with router setup

share|improve this answer
+1, though I'm surprised the setting isn't having any effect and requires workarounds. I never got this working because it required far too much effort, by the way, so I can't say whether the set-up others mentioned here works. – romkyns Jun 11 '12 at 14:45
When I quizzed crashplan support about it, they said something along the lines of "you don't need to set that, just use bandwidth throttling". I found that setting DSCP values for Crashplan using gpedit.msc is actually trivial to do, and unlike the Crashplan setting, does not ask for restarts/reboots. In a nutshell, it took a lot of effort to discover a relatively simple solution. The whole solution, now including router setup, was covered in another blog post :… – Paul George Jun 11 '12 at 15:00
Crashplan uses Java. Fairly certain they are just exposing some Java socket options there. It might be worth trying a newer JRE. – Someone Feb 17 at 16:17
Hmmm I didn't know that. However, from their website : "CrashPlan App Versions 3.6.3 And Later Windows: The CrashPlan installer includes Java and it is automatically installed with the app." nearly four years later and it still doesn't work. I've since revisited this on a linux based NAS and it's broken, but not quite so bad. The "Custom DSCP decimal value" it asks for, is actually treated as a "TOS decimal value" see setting dscp for crashplan nas – Paul George Feb 17 at 20:17

There's a setting for CrashPlan to tag its packets itself: TCP packet TOS

share|improve this answer
Do any of the popular router firmwares look at this field? Mine (DD-WRT) doesn't have any options to use this. – romkyns Apr 12 '11 at 9:28
I bet DD-WRT will do what you want, but I haven't used it so I'm not sure. If you don't mind switching firmwares, try Tomato, I bet you'll like it. It makes doing what you want easy. – Jon-Eric Apr 12 '11 at 16:22
DD-WRT doesn't have any options in the GUI for this, but apparently it's hackable via SSH... Tomato isn't supported on my router :( – romkyns Apr 12 '11 at 18:54
This setting doesn't appear to work at all under Windows 7. – Paul George Jun 13 '12 at 15:52

I think I have this working for DD-WRT + Crashplan.

First, test your connection with or similar performance tool.

  1. Configure TOS in Crashplan

    In Crashplan, go to Settings → Network → TCP packet TOS. Here I selected DSCP and input a value of 56. That corresponds to 0x38; shifting right two bits gives us 0xE, which is a DSCP codepoint we can program into IPTABLES.

    I set this value for both WAN and LAN; after saving, I did a reboot.

    To confirm this was OK, I installed Wireshark and did a trace on tcp.port == 443. After starting Crashplan I could see the output backup traffic; sure enough, expanding the IP header showed that the DS codepoint was 0xE.

  2. Enable QoS in DD-WRT

    Simply enable QoS on the DD-WRT router, as described in the above comment: NAT/QOS → QoS → Start QoS (set to "Enable").

    I programmed in 85% of my available upload and download bandwidth.

  3. Create the iptables rule

    Here, we configure iptables to pattern match on the DS code point (DSCP) and then 'set mark' to the BULK group. Go to Administration → Commands and input the following into the text box:

    iptables -t mangle -I POSTROUTING -m dscp --dscp 0x0e -j MARK --set-mark 40
    iptables -t mangle -I PREROUTING  -m dscp --dscp 0x0e -j MARK --set-mark 40

    Click "Save Firewall" to commit these changes.

    Finally, I followed up with a reboot.

  4. Test

    I found it difficult to produce a table or diagnostic that showed that my rules were in effect. So, I simply did the ultimate test, which was to re-run the performance test described above, while Crashplan was running. Success! The upload and download speeds are basically the same, even though Crashplan was running in the background.

share|improve this answer
"shifting right two bits gives us 0xE" Huh? Why do you need to shift the value two bits to the right? If you tell CrashPlan to assign a DSCP value of 0x38 it actually assigns 0xE instead? Why? – Ajedi32 May 31 at 1:13

There is a tip on the DD-WRT forum.

Use this in your firewall script, the mark values are explained on the QoS wiki page.

iptables -t mangle -I POSTROUTING -d [destination ip] -j MARK --set-mark 40 
iptables -t mangle -I PREROUTING -s [source ip] -j MARK --set-mark 40

Since they're both using iptables, you can do the same as Tomato. You just don't have a nice GUI.

share|improve this answer

I use Tomato, not DD-WRT, but I found it very easy to setup QoS for crashplan.

I configured QoS based upon destination IPs for on port 443 and classified it as bulk traffic.

share|improve this answer

Use CrashPlan's settings to rate-limit its traffic. Considering that HTTPS traffic is encrypted end-to-end (well, it's supposed to be), your router's not going to be able to determine what traffic belongs to it. The only end-run around that is if you could do QoS based on destination IP address. I don't know enough about DD-WRT to tell you whether or not that's possible.

share|improve this answer
As I'm sure you realise, I have to rate-limit it to the lowest acceptable setting, wasting all the bandwidth at those times when nothing else is using it. Which is exactly why I want QoS instead. – romkyns Feb 21 '11 at 22:48
I know what you're looking for, and understand the frustration. Unfortunately, I don't think there's anything to be done about it. – afrazier Feb 21 '11 at 22:58
Ah I see. We'll see what CrashPlan support have to say about this; perhaps there's a hidden "change ports" option somewhere... – romkyns Feb 22 '11 at 2:21

@afrazier Crash Plan PRO only encrypts traffic at 128-bit Advanced Encryption Standard (AES) protocol. That's not a call out, just an FYI-I'm a die hard CPP+ fan. OF course the data is ENCRYPTED (their end) 448-so it's beyond safe. (I say"PRO" with emphasis, no telling what "Consumer" is (???)

OK, first is the newest Fix--It allocates more Memory to CPP. Therefore, those who have the overhead, willing to give to CPP Change the INI File Found

HERE: *WIN.X" C:\Program Files\CrashPlan\CrashPlanService.ini Ubuntu · Linux · Debian /usr/local/crashplan/bin/run.conf «

GO SLOW!! THERE IS AN "-Xms15M" SWITCH AND AN "-Xmx512M" FOR THE Java Virtual Machine. *YOU WILL WORK WITH THE "-Xmx512M" (it's a compressed line, why the emphasis)

---IF you have the overhead----raise value. You should be able to increase it to 1536 or 2048 on 32-bit systems although it might be possible to go higher, especially on 64-bit systems.

IF you need to throttle back--- For Linux, stay on 64-bit (if you have a 64-bit cpu), lower the memory maximum, and use compressed ops (assuming a recent JDK) -XX:+UseCompressedOops

The URL here (but no diff than what I wrote out--wrote out for Goog bot to catch (forget to remove the -XX minus, won't find it. grin


Increasing Internet Speed (this is *NIGHT/DAY" difference on the "HOPS"

Level-3 has a "Public DNS" I changed my over to the "Known Public" Not only am I getting faster speeds (at least 4-5 MBPS MORE DOWN on Speedtest). Most critical the "HOPS" are MUCH LESS.

I was upward of 25ish hops to get to CPP. And by the time I got there it was horrendous (180-200ms+) Now, I'm around 10-hops. All "acceptable" 20ms--range

*DOGS BOLLOCKS**LEVEL 3** [][1] Updated (November 2013) Level 3--Level3-DNS

Have more, but it's 5am!!! here (thought was 1am) need sleep! later

PS--I"m on a Win.X, I found this in the jre\bin\client More Info on the -X Command Usages---NOTE THE DISCLAIMER (Subject to change without Notice)

-Xmixed           mixed mode execution (default)
-Xint             interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by ;>
                  set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by ;>
                  append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by ;>
                  prepend in front of bootstrap class path
-Xnoclassgc       disable class garbage collection
-Xincgc           enable incremental garbage collection
-Xloggc:<file>    log GC status to a file with time stamps
-Xbatch           disable background compilation
-Xms<size>        set initial Java heap size
-Xmx<size>        set maximum Java heap size
-Xss<size>        set java thread stack size
-Xprof            output cpu profiling data
-Xfuture          enable strictest checks, anticipating future default
-Xrs              reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni       perform additional checks for JNI functions
-Xshare:off       do not attempt to use shared class data
-Xshare:auto      use shared class data if possible (default)
-Xshare:on        require using shared class data, otherwise fail.

The -X options are non-standard and subject to change without notice.

share|improve this answer
Totally irrelevant - the question had nothing to do with the RAM being used by the JVM in which CrashPlan runs. – javawizard Jun 1 '14 at 21:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .