FTP, faster to PUT or GET files?
 

Any other nerds working on a Friday night?

I have a 15G file I need to transfer from system A to B. OS and patch levels are the same on both sides.

Is there any advantage to doing a GET over a PUT or are the transfer speeds the same?

What say you?

If you are meaning the putting or uploading vs downloading or getting, getting is almost always faster. Unless the FTP server is slow, downloading is faster.

In my case, it's a peer to peer connection, so not really an upload vs download. My options are a GET from system B or a PUT from system A.

'Getting is almost always faster' because most internet service providers limit upload bandwidth.

I've started the transfer and it looks like @4 hours for the 15G. I can live with that...

I think given what you've posted, it's six of one and half a dozen of another.

Is it easier to control from one computer versus the other?

That was my thought too.

I have command line on each, so no real difference that way. (IBM i5 aka iSeries aka AS/400)

The HTTP verb you use does not matter from a speed perspective. The network connections throughput will determine the speed, not the protocol.

TCP/IP Ninja has spoken!

Thanks for that.

As far as I'm concerned I issue a command, some magic happens, and the file ends up on the other side.
How the magic works, I do not know. :D

Ftp? Then I saw as/400. As/400?

:)

You know the 400 Vincent? I've been on the platform since '88.

Haven't seen it since ~98. I was a rookie then, only remember bits and pieces. Everything for me is Ubuntu now.

We're dinosaurs now. (The 400 and me... :D )

symmetrical connection (ie, not on a DSL line) then either or.

One large file will transfer quicker than many smaller files

You could also use scp and on-the-fly compression, depending on content, etc.

And don't forget the famous quote - "never underestimate the bandwidth of a black Audi wagon full of back up tapes" - and yes, depending on what you have to work with sneakernet could indeed be faster.

Today's task was to bring a new customer up in our private cloud. We did a tape transfer of the bulk of it, and I was just refreshing the last weeks transactions to do the final cut over.

Very, very exciting stuff.

LOL....I saw an AS400 once....damn toys....I heard someone even call them mainframes once....a LONG time ago. I became humongous grazing upon this stuff too (systems/networking/protocols/tuning), when I roamed. Burp...enough to last a lifetime...burp!

T-Rex

It don't matter and the Ninja's got this ;)

I was speaking from a purely technical perspective...no difference. But it's never that way....it just depends ;). I could and would "fix" that...or it might be by design.

If that's actually an "issue" for most...it's not.

Now leave me alone....cause I quit :)

FTP, TCP/IP, etc. are extremely inefficient ;).

But cheap is good too....

i hate y'all....brain is workin' on a Sat once again...make it stop :)!

FTP works with 2 separate tcp streams. One is a control channel to setup the transfer, halt etc. and the second is a data channel to transfer. that second channel does not care get or put.

But the data transfer channel can be optimized if you want to geek out. For a large file transfer you can check you max MTU on your receiving side-that is the largest data allowed in each tcp packet. Even one byte can make a difference if your settings are conservative as in a desktop system. set as large as you can and your TCP/IP stack will throttle down as it needs to (iSeries settings will likely not be the throttle). If your link is slow or noisy it will make no improvement.
Second setting to change is TCP Window size. THis is maximum outstanding TCP messages before your system sends an acknowledgement. You dont want iSeries sending 5 ships toward your port and then stop waiting for you to respond "received" before sending more. This setting controls how much data can be sent by sender before an ack is received.This makes most difference over a connection with a lot of latency like satellite.


I think thats about as optimal as you can get without compressing the data to be transferred

^^^ LOL. Buncha techno-babble...some of it might be true....lots of nonsense too. I could chat fer hours ;)

BTDT at a technical level that most (even the geeks here) can't even begin to relate too...three decades of leading/bleeding edge systems & communications....
LOVED it....back then :).

As others have said peer to peer is different than internet based FTP.

We have several PC all running Windows 10 Pro on a all peer to peer system. We also have two network based RAIDs for archiving projects.

For most data moving we use the computer that has the data to send the data to where we want it.

One reason is Windows is just sure all users are idiots, and need to be protected. It will hide some files from another computer looking at a folder of files, that are there.

We transfer a lot of files, mostly a folder at a time. Some are zillions of little 1&2 K text files, to 25 GB tif files.

The big problem with transferring a lot of little files vs. one big honker is that for each file being transferred there is the initial communications for "hey here comes this file STOR it a this location" and the acknowledgement of that communication. Across thousands of little files it adds up.

Depending on what is being copied, if any of it is being re-copied, etc. you may want to look at using rsync (yes, there are Windows version). Won't speed up initial copy but updates are deltas only.