Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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

On a 32 bit Ubuntu machine (12.04), I have a speed problem transfering files (~100MB) with sftp (command-line), from my machine to a server, on a ethernet 100Mb/s network.

The transfer starts at about 2Mb/s, then decreases slowly, until it falls below 100Mb/s and shows "stalled".

The server is a few rooms away, so I doubt it is a network issue. The server gets ping'ed correctly (less than a ms).


  • Could this be related to my machine ? To the server ?
  • What tools could I use to track down the problem ?

Aditionaly: the sftp program shows every second or so the current transfer status:

MyFile                     9%   11MB  69.4KB/s   25:20 ETA

Can that information be logged for further analysis ? Didn't find anything about that with man sftp.

I can get this though Ubuntu monitoring, as shown below, but I'd like to get the raw data. enter image description here

share|improve this question
up vote 1 down vote accepted

First I recommend running top and iotop on both the client and the server to see if either one is being overloaded CPU, memory, or disk-wise.

Also, passing the -v option to sftp may reveal additional details.

Finally, Wireshark will allow you to see the gritty details of the network activity, and perhaps reveal the types of errors that are slowing you down.

share|improve this answer
Thanks for answer. top and iotop don't seem to show anything significant on local machine (I'll ask my sysadmin to check on server). Neither does -v option, that only shows some startup information (login, keys, ...). I sniffed traffic with Wireshark, stopped after 5000 events, but analysing frames in relation to speed is not easy: lots of SSH data frames and TCP ACK. Maybe something: SSH frames are either 1514 or 2962 bytes long. 1514 is the max length for ethernet, so the 2962 bytes frames puzzle me... – kebs Jun 19 '13 at 14:46

Answering own question: Finally found the problem, that was as often very simple: sftp upload failure was due to a defective ethernet cable. This wasn't obvious, because the dowload pair worked perfectly, only upload pair seemed to suffer some form of frame failure. And this occured only when transferring large files, light upload (email or http requests) seemed to go through ok.

And indeed Wireshark helped by showing unsuccessful TCP frames, so I'll accept Nate's anwer.

Changed the cable, everything returned to normal.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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