I have an instance on Amazon EC2 which holds a large-ish file (~180MB). I need to copy that file to my local machine, so naturally I tried scp. After trying multiple times only to get max speeds of 20-30kb/s and dropped connections (only once did I reach ~200KB/s for a short while, but then the connection dropped), I tried HTTP. Over HTTP, I got 1MB/s and it went up to 2MB/s, finished the transfer in under two minutes. Over scp, the ETA was about three hours.

I know scp is slower than HTTP because of encryption, but I don't think that alone could account for a ~30x decrease in performance. So I'm guessing there's some throttling going on, probably at my ISP. Any way I could find out for sure? Or is there some other cause?

  • How is the scp upload speed to the instance?
    – MDMoore313
    Jan 19 '14 at 19:26

The typical signature of network throttling is a near-constant speed (within 10-20KB/s or so), so if you are being throttled, this is a pattern to look for. Another pattern is "bunching" or "bursting" where you get one or two seconds of high-speed connectivity, followed by a period of low-speed connectivity. If this is the case, your issue is more likely to be buffering/caching at some point.

Typically, your ISP's upstream routing equipment will be configured to QoS HTTP (or more specifically, port 80) traffic with a higher priority than all other traffic, with the (not altogether incorrect) view that most of their customers will be browsing the web, and they don't want someone else's SCP/FTP/Skype/peer-to-peer traffic blocking their pipes.

Amazon themselves don't apply any QoS (that I know of) to their instances. That said, you may be running into CPU-bound issues, especially if you're running a t1.micro (or other small) EC2 instance with a low-powered (or low-priority) CPU resource. Check your CPU steal percentage (run top and check the %st value in the top-right) to see if your CPU is being 'stolen' by other EC2 instances - this is typically the case with low-usage instances - CPU steal allows Amazon to reclaim CPU cycles from dormant/idle instances to meet demand.

  • My instance is a large (or xlarge, can't remember) one, so I don't think processing power is the issue here. One thing to note is that I am running sshd on a non-standard port (i.e. not 22), so it's probably given the lowest priority by some QoS somewhere.
    – Felix
    Jan 21 '14 at 8:49

SSHD has some overhead related to security and TCP stuck. that is why it is slower you can use scp-hpn patch, it is faster! You can see more on http://www.psc.edu/index.php/hpn-ssh


It could be either your ISP or Amazon doing the throttling. It would make sense for Amazon to apply QoS that heavily preferences HTTP as that would be their most common use case.

You can use netcat to send traffic over each port to test. You can also reconfigure SCP (sshd) to run over port 80, and see what speeds you get (or vice-versa, reconfigure your web server to run over port 22).

  • There's definitely some throttling going on, I'm trying to figure out whether it's my ISP or Amazon. I don't see how changing ports would help me do that. It's still an interesting experiment, so I'll have a go at it.
    – Felix
    Jan 19 '14 at 14:33
  • @Felix some ISPs only throttle certain ports, as they can't look @ the ssh or other types of traffic directly in some cases, but the traffic has well known ports. SSH is typically a text shell, and can get by just fine on a dialup connection, so throttling to that speed for that port won't arouse suspicion in most cases.
    – MDMoore313
    Jan 19 '14 at 19:28
  • My comment was to figure out if throttling / QoS preferencing is happening, not to figure out who is doing it. For the latter you would have to try the same tests via a different Internet connection.
    – jjv
    Jan 21 '14 at 0:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.