DOCUMENT:Q67805 30-JUL-2001 [lanman] TITLE :LAN Manager 2.0 Named Pipe Performance Information PRODUCT :Microsoft LAN Manager PROD/VER: OPER/SYS: KEYWORDS: ====================================================================== SUMMARY ======= The following questions address performance related issues involving the use of named pipes in Microsoft OS/2 LAN Manager version 2.x. 1. Q. I have heard that OS/2 LAN Manager version 2.x uses a "sliding window" algorithm to help manage its network performance. Is this related to the protocol that I am using? A. Sliding window algorithms are not limited to OS/2 LAN Manager. OS/2 LAN Manager improves upon the basic algorithm by making it more sensitive to network load and other factors. Whether OS/2 LAN Manager uses the sliding window algorithm is protocol dependent. This algorithm is a part of the NetBEUI protocol stack that is shipped with OS/2 LAN Manager version 2.x. 2. Q. Does OS/2 LAN Manager take advantage of intelligent network cards? If not, are there plans to add this functionality in the future? A. Currently, OS/2 LAN Manager does not utilize intelligent network cards, nor are there any plans to do so in the future. This is because intelligent network cards (NICs) generally lag behind other cards and are usually designed to the lowest common denominator of the PCs they must work with. What often happens is that the INC becomes a bottleneck rather then a help (especially with faster CPUs). 3. Q. If there are several named pipe connections between a client and a server machine, will OS/2 LAN Manager package together data from all the pipes before sending them across to the target machine? A. No. The underlying Server Message Block (SMB) protocol used by OS/2 LAN Manager does not support this type of functionality. Also, please note that pipes are a server resource and live on an OS/2 LAN Manager server. Whenever data is written by a client, it is immediately (with the normal OS/2 LAN Manager buffering) transmitted to the server that owns the pipe. However, whenever data is written by the server, it remains on the machine until it is requested by the client. When data is requested, the same is true. The server retrieves it out of the local pipe buffers, and the client generates a network request to the server for the data. Because pipes live on servers, any client request will generate network traffic [even a DosPeekNmPipe() call]. 4. Q. Since pipes live on the server, does OS/2 LAN Manager do anything to speed up the usage of remote named pipes? In other words, what kind of buffering strategy does an OS/2 LAN Manager server use for named pipes? A. With the exception of reads and writes, most pipe requests are some sort of a transaction and can be processed with a single network request. For reads and writes, there are several internal protocols that can be used, depending upon the availability of server resources, the mode of the pipe, and the size of the request. Listed below are the different types of protocols: - RAW protocol This protocol is used to transfer large amounts of data (up to 64K) when possible, and is only used for pipes when they are in nonblocking mode. Data sent in RAW mode is sent in a series of NCBs (network control blocks), each containing a portion of the data, until all of the data has been sent. Then, a single acknowledgment is returned by the target. - MPX protocol This is similar to the RAW protocol, except the server and client negotiate a maximum packet size that the data will be broken into. As with RAW, only a single acknowledgment is sent after the data is all transferred. MPX is not supported by the DOS redirector (and therefore will never be used by DOS clients). - Standard protocol This protocol divides the data into several packets for network transfer, and receives an acknowledgment for each packet sent. This protocol is used whenever the data will fit into the normal packet size. The server may request that a client use standard (or MPX), depending on the amount of resources it has, and other factors. - Generic transact protocol This protocol is used for APIs that do not involve read or write functionality, and is also used with the DosTransactNmPipe() API. It is similar to the MPX protocol except that it assumes 0-64K packet sizes (on both the send and receive ends). For example, this protocol allows the client [via the DosTransactNmPipe() API] to complete a relatively small write followed by a small read with half the number of packets normally required. If the amount of data to transfer is larger then the negotiated buffer size in use by the client and server, it will be divided into packets of the negotiated size (as with the MPX protocol). Beyond the various protocols that OS/2 LAN Manager may use internally, the server end that owns the pipe also includes some enhancements (which are part of the HPFS386 IFS shipped with OS/2 LAN Manager version 2.x). Essentially, for remote pipes with HPFS386.IFS installed, OS/2 LAN Manager is able to bypass the OS/2 kernel in many cases, thus saving unnecessary ring transitions and movement of the data. In the normal case (without HPFS386), data is transferred from the network into OS/2 owned pipe buffers, and then finally to the application's buffers. With HPFS386 installed, OS/2 LAN Manager will attempt to copy the data directly to the application's buffers. It will always be able to do this if a read is outstanding when the data arrives (this is the advantage of dedicating a thread to reading a blocking-mode named pipe). If no read is outstanding, OS/2 LAN Manager will hold the data in its own internal buffers as long as it can (waiting for a read to be issued). Additionally, with DosTransactNmPipe() calls, the data written in response can be taken directly from the application's buffers, thus bypassing (again) the OS/2 internal pipe buffers. An application will get the best pipe response time by dedicating a thread to the pipe and blocking on reads. This will be faster than either using a semaphore or polling. Additional optimizations for named pipes exist in the NetBEUI protocol stack. For example, some requests may even be handled at interrupt time. 5. Q. What can an application do to obtain the best possible named pipe performance? Foremost, the server should be using HPFS386 so that OS/2 LAN Manager can bypass as much of the OS/2 kernel as possible. Also, as noted, if resources allow it, an application will get the best possible performance by dedicating a thread to a pipe so that when the data arrives it can be transferred immediately. If the amount of the data to be transferred is small, an application may want to consider using the DosTransactNmPipe() call (to minimize network traffic). On the server, for small data I/O requests, the number of request buffers specified is important. Always ensure that NUMREQBUF is set with the following formula as a minimum, to a maximum of 300: (3 * ) + (2 * ) For large data transfers, MPX is normally used with OS/2 clients and RAW for DOS clients. For MPX, it is important to have as many request buffers as necessary to hold a 64K write (using the default, this is 16 request buffers). To support RAW mode transfers, the server needs big-buffers; the number of these that exist is controlled by the NUMBIGBUF keyword (at a minimum, three should be specified if DOS clients exist on the network, even if HPFS386 is being used). Additional query words: 2.00 2.10 2.10a 2.20 ====================================================================== Keywords : ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 2001.