Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Recently I was making a few attempts to copy&paste a big (1.2 GB) file to remote computer over RDP. The remote computer is virtual testing machine with MS Windows Server 2008 Datacenter.

First I tried to copy&paste before midnight when the transfer speed was limited by client computer ISP to 100 kB/s. So, it required a few hours and I was forced to cancel transfer since remote desktop became too unresponsive and sluggish (slow). So, I re-started it over midnight when my local transfer speed is over 4MB/s.

So, my impression is that independently on speed (broadband) of copy&paste transfer the remote computer becomes sluggish while copying over RDP. At the same time downloading from internet doesn't make remote host sluggish.

AFAIU, it is because clipboard of remote computer and so its memory becomes overloaded by transfer.
How can I control (restrict) the usage of clipboard for specific process (pasting of file)?

What are the possible way to control it?

Update:
After reading that slow speed of transfer is caused by encryption used for copy&pasting over RDP and since I believe I am more interested in overall efficiency: both the time, or rapidness, of getting file as well as possibility to work without waiting, I changed the question title from:

  • How to control the usage of remote desktop clipboard usage for pasting a big file?

to

  • How to better copy&paste big files over RDP?

For example, is it better to copy&paste one huge (zip) archive or unzip it and copy paste a folder with unzipped files?

And more exactly I wanted to ask:

  • What are possible ways to improve overall experience:

    • the speed of transfer (i.e. availability of needed file)
    • responsiveness of remote host (making remote coputer available for work before completion of copy&pasting)?
share|improve this question
add comment

4 Answers

up vote 2 down vote accepted

When you say a Zip file, do you mean an uncompressed archive that would be the same size as all the individual files? Or do you mean a compressed archive? Because right there, if you are talking about a compressed archive, you'd have a faster transfer, which strictly speaking would be better. Of course, if you take into account the amount of time it takes to make the archive, and how long it takes to extract the archive, then the specs of both machines come into play as to whether the archive is better than loose files.

Now, since you are talking about RDP (as opposed to VNC), the bandwidth usage of the remote connection is quite a bit. RDP is more responsive than VNC, the color depth is (by default) more than 256 colors (32 bit if you don't change it), the screen size will be the size of your desktop, etc... all of these factors affect how much bandwidth is being used just for the remote connection. If you drop things like... the size of the remote desktop, and color depth to 16 bit or less, make sure you aren't sharing sound, etc... this will use less bandwidth for the remote connection, so that when you are transferring files, the remote session should be more responsive.

In the end though, unless you can throttle the file transfer, the remote session is going to get sluggish no matter what you do while you are transferring files, since as much of the available bandwidth as possible is going to be used for the transfer between the remote machine and your machine.

EDIT

You are attempting to find a simple way to transfer files WITHOUT affecting the quality of the remote connection. It doesn't matter if they are large files or small files. At your end (the client machine) you are squirting small amounts of data up to the remote machine (server machine). You know... typing, mouse commands, etc. The server is sending large amounts of data to you all the time, in the form of the images that are making up what you see across the remote connection. So, before you transfer any files, you are ALREADY transferring a large amount of data in one direction. That's why I brought up the things you could do to reduce the amount of data you are transmitting.... namely use a smaller resolution for the remote machine on your desktop (as opposed to full screen).... reducing the number of colors from 32 bit to 16 bit or even 8 bit. Those two steps right there will drop the amount of data you are transmitting from the server (remote) to the client (you). It also means that when you start transferring files along the same connection and route, your remote connection will suffer less.

As I said... nothing you can do will make the connection stay crisp and responsive. Why? Because as soon as you start transferring files from the server to the client, this is going to suck up every bit of bandwidth that is available along that pipe.... and you are already using some of the bandwidth along that pipe for the remote connection itself.

First I tried to copy&paste before midnight when the transfer speed was limited by client computer ISP to 100 kB/s. So, it required a few hours and I was forced to cancel transfer since remote desktop became too unresponsive and sluggish (slow). So, I re-started it over midnight when my local transfer speed is over 4 GB/s

So when you first tried the transfer, you had a download connection of 100kb/s. You were moving 1.2gb of files as fast as possible, which would push to eat up as much of that 100kb/s as it could. Which would leave what room for the data supporting the remote desktop connection? So, of course it would be sluggish and unresponsive. The only thing you are not also taking into account, is the UPLOAD speed of the server. If the upload speed of the server is less than your download speed... and in this perfect hypothetical the route between the server and you allowed for this upload speed to remain constant, as soon as you start to transfer the files, just about all of that bandwidth is going to be eaten up by the file transfer, which will make the remote connection suffer.

Why?

Because there is nothing throttling the file transfer to a specific speed, or a percentage of available bandwidth, it is going to attempt to use every kb/s it can. By the nature of things, this will make the remote connection suffer.

Even transferring the files from the server to a third party (like an FTP server somewhere) would make the connection sluggish during that transfer, because again, as much of the available bandwidth as possible would be allocated to that transfer. Once that transfer was done however, you would be able to download it from the FTP server with no effect on the responsiveness of the remote connection... again because your incoming pipe after midnight is much larger than the server's outgoing pipe.

So, I would try reducing the quality of the remote connection.

share|improve this answer
    
The size of compressed arhive file is practically the same as uncompressed files. The time of compressing and uncompressing is not an issue since they do not freeze the system for working. And I can use them both as uncompressed bunch of files or compressed one file (in the latter case by mounting a virtual drive) –  Gennady Vanin Novosibirsk May 28 '12 at 6:24
    
@WebMAOhist then since the files won't compress much, it isn't worth it to zip them up, since you are adding the archiving and extraction time to the total file handling time (includes transit), and you gain nothing by putting it in an archive. Still brings us back to bandwidth for remote session + bandwidth for transfer issue. I'll append the answer since this is going to get longer than a simple comment. –  Bon Gart May 28 '12 at 16:31
add comment

I use robocopy on my windows 7 box, using the unc name \\tsclient.

share|improve this answer
    
Thanks. Well, the answer(s) so as I understood is: "Do not use remote copy&paste" for big files. There are many other choices but I already completed transfer by c&p and only after that started to think. Shall look for alternatives and think b4 doing next time –  Gennady Vanin Novosibirsk May 28 '12 at 6:32
add comment

Don't use C&P, use Drag & Drop instead. Open Windows Explorer on the remote system. Your local drive should appear at the bottom of the drive list in My Computer. It shows up as "C on your_computer_name". Now you can D&D the file from one system to another.

I don't remember if there is a registry setting or RDP option to enable this feature

share|improve this answer
    
I tried it, it is not available –  Gennady Vanin Novosibirsk May 28 '12 at 2:43
    
It is an RDP setting -- off by default. Start the RDP client, click options and click the "Local Resources" tab. Click more and tick "Drives" –  Chris_K May 28 '12 at 3:33
    
I am not able to copy&paste at all w/o checking options in "Drives" of "Local Resources" RDP options. So, after checking them, I can C&P but cannot D&D. Then, really, isn't D&D is just a more funny way of C&P? Where is the win? –  Gennady Vanin Novosibirsk May 28 '12 at 7:29
    
D&D might use a different process "behind the scenes," so it might work, even if C&P doesn't. Have you tried to D&D? –  Tom May 28 '12 at 15:57
    
Ooops, I was wrong. I realized that you did mean D&D inside the same remote machine, as my local drives appear in file system of remote machine, which I have noticed only after this discussion –  Gennady Vanin Novosibirsk Jun 25 '12 at 2:20
add comment

As suggested in his answer by @Tom, it is preferable to D&D the files instead of C&Ping them. This has the added benefit of circumventing a bug that interrupts the file transfer if you use Ctrl+C on the client machine.

share|improve this answer
add comment

Your Answer

 
discard

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.