Dale un vitazo a esto.
Juan Carlos Santos - You can view the document at the following URL http://www-912.ibm.com/8625680A007CA5C6/1AC66549A21402188625680B0002037E/0B480D3755AFC23286256A3E005F5988 This document and many others can be found by selecting the "Technical databases" link at the iSeries Technical Support website at the following URL: http://www.ibm.com/eserver/iseries/support While you are there, check out other exciting offerings such as iPTF and Recommended Fixes. We show you the quickest way to keep your iSeries systems current on fixes. IBM Support Line Technical Document Document Number: 23091731 ____________________________________________________________ Functional Area: Communications-TCP SubFunctional Area: FTP SubSubFunctional Area: General ____________________________________________________________ Product: TCP/IP CON UTIL (5722TC100) Release: V5R1M0; V5R2M0; V5R3M0 Classification: Public Use Keywords: FTP ____________________________________________________________ Document Title:FTP Performance Considerations Document Description: This document addresses the many of the FTP performance questions received by Support Line on a regular basis. FTP performance issues are handled through the Consult Line offering 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. 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. _____________________________________________________ Forum.HELP400 es un servicio m�s de NEWS/400. � Publicaciones Help400, S.L. - Todos los derechos reservados http://www.help400.es _____________________________________________________ Para darte de baja, env�a el mensaje resultante de pulsar mailto:[EMAIL PROTECTED]
