About all Linux LAN only.

For this, I am only interested GUI assisted apps.

From what I have been reading, non-encrypted tranfer of files on my LAN should be faster than the same files transfered using encryption. Is that correct?

I think all the GUI assisted transfer apps I have gotten to work are encrypted, namely;

nfs
samba
sftp - I think sftp runs over ssh, I know it is on port 22


The only thing I have tried so far that I think is unencrypyed - is to install and run a basic ftp server on one computer and make the client connect from the other. I have not been successful with that yet, so before I spend more time trying to make it work I am asking for advice.

One computer is an old, single core Amd Athlon 3000
The best connection I think I have is my 10/100 ethernet with crossover cable.

I am getting transfers in the 4-6 MiB/s range with sftp.

Might I see speed go up enough to make a pleasent difference, just from changing to an unencrypted transfer method?

Any ideas for (GUI assisted) apps that might do the trick?

I have read a large amount about how connection speed is not the same as actual transfer speed and there are 500 gadzillion factors that effect the speed (everything from the cpu to the kitchen sink apparently) etc...etc... I don't want to spend a huge amout of time on this setup, its old as dirt anyway and probably not long for this world.

But I would love to try any quicker ideas if I knew what to try.

Thanks

If data is encrypted or not does not influence speed of transfering it. If you have not the same speed with encrypted data and not encrypted it is rather due your microprocessors low speed. It need to encrypt data and microprocessor on the other side decrypt this data - it consume time, which sometimes is greater than maximum speed of your network.

Thanks eSelix,

I understand my cpu may be a problem, might using unencrypted lesson the load on cpu and therefore allow more speed?

If so is basic ftp a way to try that?

I'd say that encryption could cause a noticeable decrease in total system data. Depending on the encryption it may add enough to each packet to change how well the lan work. It may cause issues with switches and routers as to how they work. Setting to start sending data at once may assist in routers but that can cause other issues. Also is the high amount of cpu it may take on some system to use encryption.

If you are truly on a trusted lan then tunnels and encryption may not be needed. A somewhat secure method may be to do something like Barracudaserver https server.

Thanks jefro,

Barracudaserver looks like fun. If I understood what I read about it, it reminds me of a stand alone version of any number of webpage control interfaces, like what you get with printers or proprietary backup back up devices. Fun, but more than I should need.

Thanks again.

edit to add;

I see I did not make it clear in my OP. This is only 2 computers connected directly with a crossover ethernet cable. That may not even be called a LAN huh?

I could say it is LAN. You do not need encryption in this scenario. You can try unsecured ftp to compare.

Thanks eSelix,

I will try again to get that basic ftp working then. I was not really even sure it was unencrypted but based on your last response it seems so.

Unless someone jumps in and says "There's a Gui front end for <insert protocol/method here> that is also unencrypted, but might be easier to get working"

Thanks again.

I'm off to mess with it.

FTP is not encrypted.

It might be more enabling for persons to help you if you described one particular thing you were trying to do. Granted you may be looking to do several things, but perhaps start with one concept. You keep saying GUI based. That's neither here nor there, excepting for ease of use; however when you consider that a GUI introduces abstraction which hides the details which are being done at the network layers, then it all becomes more obscure.

I do understand that you have 2 computers hooked up back to back. If you're trying to facilitate file transfer between them and wish it to be faster, then please say that, or whatever the first level equivalent is. Because there are other transfer means which may serve you better.

If instead you just wish to know details about network protocols, how things are affected by whether or not a protocol or application uses encryption or some other encoding, then please say that.

You say your network is 10/100, well it should be either 10 or 100, not both. When these two computers establish their connection, if they're both Linux, you can run the command "ethtool" to see your interfaces. You may have to install that, it's not always included, but you also will have to run it with sudo so you can properly see all attributes for your interface. Typically it will be eth0, but check that using "ifconfig" to see what network interfaces you do have. Ethtool will show you the active speed of your link. If it says 10Mb/s, then you're not getting 100 and one side of this back to back does not support 100M speed. Ethtool will also show you "supported" modes, therefore it will show you which side of your link does not support 100M, if this happens to be the case.

There are gui's that can help create a ftp server.

Many browsers support ftp://someuser@192.x.x.x easily.
No need to ftp someuser@192.x.x.x

The consensus in this thread is that it doesn't make a difference:

http://stackoverflow.com/questions/5...oes-ssl-impose

It makes a difference for compression. Encrypted files don't compress. Unencrypted files MAY compress depending on type of data.

For future searchers.

I finally got pure-ftp working, and I guess the "other factors" that affect transfer (sftp vs ftp) can at times be dealmaking large.

On the same wire where I was getting 4-6 mbps with sftp I get 11-13 mbps with pure-ftp. It was well worth hanging in there and messing with it till I got it working.

Thanks everyone, especially those who encouraged me to hang in there and try it out, just to see how much other factors were effecting this.

Summarizing some of the previous comments, the point is that the (max avail) actual wire speed does not change, BUT compressing and/or encrypting (& de-crypting) the data adds to the overall time.
Encrypting on the fly (eg scp/sftp) can make it appear that the wire speed is slower, depending on how fast the cpu is (for very large files, disk speed affects it also).
You can pre-encrypt via gpg, then just eg ftp the resulting file (although of course you have to de-crypt after)

1 members found this post helpful.