[Editor's Note: Share your NT discoveries, comments, experiences with products, problems, and solutions and reach out to other Windows NT Magazine readers (including Microsoft). Email your contributions (400 words or less) to Karen Bemowski at kbemowski@winntmag.com. Please include your phone number. We will edit submissions for style, grammar, and length. If we print your letter, you'll get $100.]

After reading "Optimizing NT RAS" (May 1998), Taed Nelson asked me why the Windows NT 4.0 serial.sys driver installs with the default first in, first out (FIFO) values of 8 for the receive buffer (RX) and 1 for the transmit buffer (TX). I decided to investigate the matter in the Microsoft Windows NT Server 4.0 Resource Kit.

The resource kit's Registry documentation refers you to a nonexistent Knowledge Base article (Q112559), making the mystery even stranger. You can't help but wonder why Microsoft removed this article. And you are still left wondering why Microsoft selected the NT 4.0 default values of 8 for RX FIFO and 1 for TX FIFO, especially when Windows 95 uses the default values of 8 and 16, respectively.

You can improve modem performance by increasing the TX FIFO value to 16. In regedit, change the TX FIFO value in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Serial subkey to 16. However, before you experiment with this modification, make sure you have backed up your Registry. In addition, be aware that modifying the TX FIFO value is a global change that affects all serial ports on the system. As a result, this change might cause problems for other types of devices (such as plotters, mouse devices, and digitizing tablets) attached to serial ports. After you change the TX FIFO value, verify whether all the serial-based devices are working properly.

If you encounter any problems with particular devices on other component object model (COM) ports, you can make the following change, which is specific to a particular serial port. In the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Serial subkey, create an additional Registry subkey for a specific serial port number by adding a Serialn key (where n is the number of the COM ports connected to the dial-up adapter) under this key's Parameters subkey.

For example, a specific entry for COM1 is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Serial\Parameters\Serial. Inside this newly created key, create the same REG_DWORD value for TX FIFO as that found in the Serial subkey and set it to the desired value for that port (e.g., 16 decimal). You can also create custom values to this port for other entries, such as RX FIFO.

Try Before You Buy
I have been testing Symantec's pcANYWHERE32 8.0 for Windows NT 4.0, NT 3.51, and Windows 95 in a development lab to determine its compatibility and functionality with my company's legacy systems. In particular, I wanted to test pcANYWHERE32's ability to upload and download files to and from distributors' bulletin board systems (BBSs) using Pulsar Systems' ZMODEM.

My company has been running pcANYWHERE32 on UNIX servers in its US systems. For several years, I have used a script to automate the ZMODEM transfers. However, my company plans to replace the UNIX boxes with NT. Initially, I believed that I could still use pcANYWHERE32 with NT to maintain the BBS file transfers to the distributors. But when I tested pcANYWHERE32 for NT and Win95, I discovered that Symantec has not incorporated the functionality of the earlier versions into version 8.0. This version doesn't support script-based file transfers to legacy BBSs.

Calls to Symantec have been fruitless. No one seems concerned that this feature doesn't work with NT. (It works with other platforms, however.) And no one appears to know whether this feature will ever be functional. So buyer beware. Before you part with your hard-to-come-by IS budget and purchase a product, make sure it works.

Remotely Change the LMHOSTS Table
Suppose you have a network of Windows NT workstations at local and remote sites (some of which are far away). You don't have either fixed IP addresses or Windows Internet Naming Service (WINS), so whenever you install a new computer, you must change the LMHOSTS table. You can perform this task remotely by using the .reg file in Listing 1 to change the Registry keys.

In Listing 1, Elnk31 and AMDPCN1 are network adapters that might exist in a computer. Although this file contains entries for several adapters, NT will use only the appropriate one.

To install the changes in the Registry, use the .bat file in Listing 2, put in the logon script, and reboot. The script in Listing 3 will not only implement the Registry changes but also implement the WINS and Domain Name System (DNS) policy. Before you use this listing, change the IP and domain names to the ones in your network.

   Prev. page   [1] 2     next page



You must log on before posting a comment.

If you don't have a username & password, please register now.

Reader Comments

Thanks for Sean Daily’s Reader to Reader: “Unsolved Mystery” (August). I decided to change the TX FIFO buffer to 16, per the author’s recommendation. I noticed some improvement in my U.S. Robotics 56Kbps V.90’s performance. However, I decided to experiment and change the RX FIFO buffer to 16. The result was a marked improvement in downloading pages. The last time I saw this kind of performance was when I was operating on the company network, which has a T1 connection. I changed both my systems (which have 56Kbps modems), and the results were the same. The only question I have is whether any risk is associated with changing the buffer values. With the performance I’ve achieved, I’m prepared to leave my systems as they are until I find some negative aspect that forces me to revert. Thanks for the great tip.<br> –Jack Terwiel<br><br>

<i>The only potential problem that exists in changing the COM port TX or RX buffer values is loss of performance or functionality, which is evidently not the case for you. If you aren’t experiencing any loss of functionality or performance after making the changes (and are reaping a performance benefit), it’s safe to keep the values at whatever optimal setting you discovered during your experimentation.<br> Hardware doesn’t limit the buffer values, but Windows NT imposes soft limits on them. However, these limits are based on the actual buffers on most modern COM ports. Microsoft’s documented limit for the TX FIFO Registry value is 14 (with possible incremental values of 1, 4, 8, and 14), and the documented limit for the RX FIFO value is 16. (For more information about these Registry entries and their potential values, see Microsoft Windows NT Server Resource Kit’s regentry.hlp file.) These limits are based on the recommended maximum values for a National Semiconductor 16550-style UART, the chip driving most modern COM ports.<br> --Sean Daily</i>

Jack Terwiel