Operating System - HP-UX
1855947 Members
3199 Online
104107 Solutions
New Discussion

Re: slow or Incomplete transfers ftp & uft

 
SOLVED
Go to solution
A.K.
Frequent Advisor

slow or Incomplete transfers ftp & uft

Hello All,
We are transferring big files (5 – 7 GB) between our main office in North America and one of our branches in Africa via ftp or uft (both locations uses N class HPUX 11.00).
Recently we noticed that the transfers takes much more time than it used to in the past and sometimes just timeout.
The network administrators on both sides claim that it is not a network issue.
What can we do on the server’s side in order to increase the speed of the transfer?
Someone here suggested changing the setting for server window speed
to 64K (ndd –set tcp_recv_hiwater_def )

Is that a good idea?
Will it speed up the transfer?
What are the side effects?


Thanks,
A.K.
2 REPLIES 2
Christine Hartman
Valued Contributor
Solution

Re: slow or Incomplete transfers ftp & uft

A.K.
depends on the speed of the connection wire....if you use the -B option for ftp (and specify 64) to use a larger buffer size....it will speed up the transfer on fast link...but if your link is slow (i.e. X.25) then it will actually slow down your performance. The ftp man page does talk about this option too.
Hope this helps.
Greg Vaidman
Respected Contributor

Re: slow or Incomplete transfers ftp & uft

setting the tcp_recv_hiwater_def and tcp_xmit_hiwater_def to higher values can have performance benefits on slow links, although I haven't seen as much benefit to ftp as to sftp, but your environment may be different from mine.

you'll want to experiment with these values, as setting them higher increases the minimum memory utilization of every tcp connection on your system. you'll want to find the best bang-for-the-buck number, i.e., don't use 128K vs 64K if you only get a small performance benefit.

remember to set the value at both sides, because ftp could run active or passive, and the parameter only affects side that does the work in the transfer.

it's not so much an issue with ftpd because it starts on-demand from inetd, but if your other protocol (i'm not familiar with UFT) starts on its own outside of inetd (like sshd, for example), you'll want to restart the daemon after changing the parameters.

good luck!