>I have a truly puzzling ftp question. Between heterogenous platforms, I am
>seeing radically different ftp performance when doing puts than when doing
>gets. I am seeing this in two separate instances
>
>Instance #1) From my NT desktop to our P390 Mainframe Emulator I can do an
>FTP put of a 100MB file relatively quickly. A get from the mainframe to my
>PC of the same file runs extremely slow or hangs altogether. We have
>experimented with adjusting MTU size, full or half duplex, etc., to no
>useful effect.
What about binary vs. text mode? Given that the mainframe (probably?)
uses EBCDIC while NT uses ASCII if there is automatic conversion going
on one way rather then the other that could slow things down alot.
Also you are not only testing network performance, but also disk and
filesystem performance. If you are seeing actual hangs though, you
may very well be seeing some bizarre network problems. I'ld suggest
using some kind of network monitoring program and see if you can find
anything funny about window size negotiation or packet
acknowledgements.
>Instance #2) From a solaris box in our US office to a solaris box in our UK
>office we see radically different times for puts and gets. A put inititated
>in our US office to the UK server takes about twice as long as a get of the
>same file back from the UK office.
>
>In this second instance, we have have two connections to our UK office, a
>128k direct frame link and a 2Mbit ATM link that is shared with our other
>European offices. All TCP connections initiated in the US office flow over
>the 128k frame link. All connections initiated in the UK office flow over
>the 2MBit shared ATM link. FTP transfers initiated from the UK office to the
>US office (solaris to solaris, again) take the longest of all, about 3 times
>as long as the gets initiated from the US side.
>
>What is going on here? Why in the local office from desktop to mainframe
>are puts faster than gets and why on the slower frame link from US to UK are
>puts always faster than gets?
Some of this may be easier to explain. If I remember correctly, FTP
uses a seperate TCP connection for the actual data transfer. In
normal (not passive) mode, the remote FTP server initiates this
connection back to you. This is irregardless of the direction the
data is going to flow. If you put your ftp client into 'passive'
mode, then the data connection is initiated by your client to a port
that the server allocates. Try doing puts & gets in both passive (and
non-passive) mode from the same end and see what happens.
Also, what do you mean when you say that connections 'flow' over the
different connections depending on which side of the Atlantic your are
on? A TCP 'connection' always has IP packets flowing in both
directions. Unless you are actually using different IP addresses at
both ends when you do you're test then it is highly unlikely that the
same direction of a 'flow' is actually going on different links
depending on which end you initiated it from. Once the TCP data is
stuffed in an IP packet, it's USUALLY pretty much on its own and
routers don't care with what activity it's associated. It is,
however, very possible that packets going in one direction take one
path while the other direction uses a different path. If you are
using traceroute to determine the path and you see different paths
from different ends this is probably why. Traceroute only tells you
what path outgoing packets take to reach a destination. You have to
traceroute from the other end to see what path your return packets are
taking. My guess is you are seeing what is called a 'split path' for
IP routing. From what I've heard, this is generally considered a 'bad
thing' and can do funny things to TCP's estimates of congestion etc.
That's, of course, on top of the problem in this case that the split path
has very different speed characteristics depending on the direction
that the packet is going.
Good Luck,
Bill Bogstad
---
Send mail for the `bblisa' mailing list to `[EMAIL PROTECTED]'.
Mail administrative requests to `[EMAIL PROTECTED]'.
