Troubleshooting
Problem
FTP performance considerations are discussed in this document.
Resolving The Problem
This document addresses the many of the FTP performance questions received by the Rochester Support Line on a regular basis. FTP performance issues are handled through a consulting agreement because nearly all such problems are the result of network, configuration, or user problems.
Network Issues
The most common cause of slow FTP performance is dropped packets in a network. A communications trace will show many repeated requests for frames, repeated or missing acknowledgements, or both. Frequently, a file transfer will start out transferring data quickly, then it will become progressively slower as the IBM OS/400 or IBM i5/OS tries to recover from missing or lost packets.
In many cases, the only reliable way to troubleshoot these problems is to perform 'sniffer' traces at both ends of the circuit at the same time, and check to verify that packets being sent from each end are being received on the other.
Transfers Are Faster in One Direction Than in the Other
It is not uncommon for file transfers to be faster in one direction than in the other. Factors that affect this include:
| 1. | Trimming of Trailing Blanks In the default ASCII transfer mode, the sending machine trims trailing blanks. This requires a lot of CPU. |
| 2. | CPU Rating of the Machine Sending the File FTP is very sensitive to differences in CPU rating. |
| 3. | Interactive versus Batch File Transfers Models with higher batch CPW ratings will usually perform better sending files in batch mode, rather than interactively. |
| 4. | Availability of Sufficient Storage Pools for Interactive Subsystem |
| 5. | Priority of Interactive Jobs |
| 6. | Network Differences Often, a network cannot handle data at the same rate in both directions. The iSeries can generate a very large amount of network data quickly because of its ability to consolidate many different kinds of server and application engine tasks. Often, this is sufficient to swamp a local or nearby network switch or router, resulting in discarded frames and re-transmissions. This is usually more noticeable in one direction than in the other. |
Other Factors Affecting FTP Performance
| 1. | Maximum Transmission Unit The default MTU size on earlier releases of OS/400 or i5/OS was 576 bytes. Most networks can handle much larger frames. Use the CFGTCP command, option 2, to examine the defined network routes. Select option 5 next to each route and view the parameter, "Maximum Transmission Unit". This should be set to *IFC. Then, check the Interface definition, using the CFGTCP command, option 1. Use option 5 to view the interfaces. Here, "Maximum Transmission Unit" should be set to *LIND. Finally, you can check your line description to verify that it is set to the normal defaults for framesize, and that the Source Service Access Point (SSAP) "AA" is set for a maximum framesize of *MAXFRAME . CFGTCP, Option 1, will show you the name of the line description associated with your TCP/IP interface(s). Then, use the WRKLIND linename command and select Option 2 to examine the Maxframe parameter on the first page, and the "AA" SSAP on the second page. NETSTAT, Option 2 - F11, can be used to view the actual MTU size being used on a route. |
| 2. | Send and Receive Buffers Use the CHGTCPA (F4) command to view the TCP/IP Send and Receive buffers. These are set to a value of 8192 bytes by default (65536 at R610 and above). In most network environments, performance will be improved by increasing these buffers to a minimum of 65536. The value used should be an exact multiple of 8192. Best network performance should be achieved when these buffers match exactly the size of the buffers in any network routers. At V4R5 and V4R4 (with PTF SF56719), increasing the Send Buffer also allows the system to use larger TCP/IP Window sizes, which can be very important on large file transfers over long distances. |
| 3. | Path MTU Discovery On V4R5 and later, Path MTU Discovery is enabled by default. This lets OS/400 and i5/OS negotiate larger frame sizes for transfers. Use the CHGTCPA command to verify that Path MTU Discovery is set to *YES. |
| 4. | Hang at Client Connect Time This is usually the result of a DNS problem. It can be circumvented by having the local system TCP/IP address in the Host table (CFGTCP, option 10), and setting 'Host Name Search Priority' to *LOCAL in CFGTCP, option 12. The FTP server looks its own name up in DNS or the local host table each time a client initiates a connection. |
Historical Number
23091731
Was this topic helpful?
Document Information
Modified date:
18 December 2019
UID
nas8N1017395