VOICE Home Page: http://www.os2voice.org
[Newsletter Index]
[Previous Page] [Next Page]
[Features Index]

October 2000

How to Supercharge OS/2 Warp -
Part 5

By Christian Hennecke ©October 2000 

The OS/2 Files: http://www.os2world.com/os2files/

IBM Device Driver Pak Online (Device driver repository) - http://service.software.ibm.com/os2ddpak/html/index.htm

Welcome to the fifth part of our series on OS/2 tuning. This month we are closing the series with a look at printing and networking.

This article is part of a series on improving your OS/2 system that is published in the VOICE Newsletter. Last months' articles covered CD-ROM and harddrive performance, responsiveness and stability issues, memory consumption and video performance. All the tips can be viewed in English as well as German language at my homepage at http://www.os2world.com/os2files/ by selecting the tuning link.

Again: These tips apply for the most part to all versions of Warp, unless otherwise noted. They also take into account that you might be running an old, slow machine. There may be errors or omissions that might lead to your machine blowing up. I strongly advise you to make a backup before fiddling around with your system's settings. You've been warned.

For credits please see "How to Supercharge OS/2 Warp - Part 1" in the July 2000 issue of the VOICE Newsletter.

7. Printing

7.1 Hardware

The last years saw both a dramatic increase in printing quality and decrease in price. Even very low-cost printers offer a minimum resolution of 600dpi or 720dpi today and as soon as you are willing to spend a bit more 1200 or 1440 dpi are the standard, and all this in nice colors. While it certainly is a Good Thing(tm) to be able to print with photo quality there is a price you have to pay. And as you don't do it with money the printer manufacturers decided to get the price by reducing the functionality of the printers' hardware resulting in so-called GDI printers (Graphics Device Interface - The graphics display system in Microsoft Windows, that is a win-printer). The missing functionality is then taken over by the printer drivers, meaning that your computer has to handle it and thus the CPU load increases much during the printing process. For example it has been reported by several people that a Lexmark Z51 will simply block your system while printing unless your machine is equipped with a AMD K6/Intel Pentium 400 class CPU.

7.2 Drivers

As with other kinds of hardware, printer driver support for OS/2 is a bit critical. While IBM itself offers own drivers for most printers at their site Device Driver Pak Online most of those drivers are restricted as far as functionality and printing quality are concerned. An exception are printers by EPSON and Lexmark, beginning with lower mid-class models. For these the manufacturers provide their own OS/2 drivers that are well able to compete with their Windows counterparts in terms of functionality and quality.

7.3 Printer access

A good way to speed up printing in general is to edit the CONFIG.SYS file. Find the line that says BASEDEV=PRINT01.SYS. Now edit it so that it reads BASEDEV=PRINT01.SYS /IRQ. This dedicates an IRQ number to the printer, instead of polling for free IRQ numbers, which is much faster. You can also specify the IRQ directly by using /IRQ:x.

Edit your CONFIG.SYS file and find the line that says PRINTMONBUFSIZE=134,134,134. The 134 represents a print buffer (like a cache) in bytes, one each for LPT1 through LPT3. Change the first 134 to read 2048 if you are only using LPT1. Reducing the values for LPT2 and LPT3 has no effect as 134 is the minimum used. If your machine hasn't much free RAM left try 1024 instead of 2048.

7.4 Spooler

If you are using your printer to print only one thing at a time, or don't have a printer, then you can save some memory by disabling the print spooler. Go into your OS/2 system folder and go to System Setup. In there you will find the Spooler icon. Right click on this icon to bring up it's menu, from which you can disable the spooler function.
WARNING: Disabling the spooler will pretty much prevent you from multitasking while the printer is doing its job. If you're printing a large document you can go and make yourself some cups of coffee! So you'd better only disable the spooler if you really need the additional RAM.

You can influence the spooler's behaviour by adjusting its print priority. Lowering the priority may make your machine more responsive during printing while increasing it will speed up the printing process. Changes become effective on closing the object. The effect very heavily depends on your printer and its driver, so you should experiment a bit.

By default the spoolpath, i.e. the directory where the spooler saves temporary files, is placed on the bootdrive. The temporary files can get very large, so you should assign a drive with enough space going to the Spoolpath tab of the Spooler object.

7.5 Printing from Win-OS/2

When printing from Win-OS/2 keep the Win-OS/2 printmanager disabled, i.e. closed, unless you use a printer connected to a COM port. Choose LPTx.OS2 as printer port instead of LPT1. This will direct the printer output to the OS/2 spooler and ensure that printing is done in a seperate thread.

8. Networking

Please note that all changes made to your TCP/IP, MPTS, LAN requester etc. configuration require a reboot to become active.

8.1 Hardware

8.1.1 Network adapter's MAC address

When you purchased your network adapter card it probably came with some kind of configuration utility, since most cards don't use jumpers anymore. If you have this software, run it to get the 12 digit alpha-numeric network adapter address. (WARNING: Don't run this program while any network drivers are loaded or you will probably destroy your network interface card!) Write this down and keep it in a safe place. To make this address known to OS/2 start the MPTS configuration program MPTS.EXE (MPTS in the system configuration folder). Choose Configure. Select LAN adapters and protocols and press Configure again. Now select your networking card's driver from the Current configuration list and press Edit. Enter your card's address into the Network adapter address entry field preceded by a "@". If you are using the NetBIOS protocol repeat the above procedure for its settings. Doing so with our network resolved some mysterious crashes we were having, and generally sped things up a lot.

8.1.2 Selecting transmission modes

Most of today's network interface cards come with a transmission speed detection so they can automatically adapt to network's given transmission speed at boot time, e.g. 10Mbit fullduplex or 100Mbit fullduplex. However, at least one machine has to explicitely set the mode for the others to be able to detect it. Otherwise or if detection fails for another reason the slowest mode will be selected, e.g. 10Mbit halfduplex. To specify the transmission speed invoke your network card's driver's settings again like described above. Now you should be able to enter the preferred transmission mode into the Medium type entry field. You can have a look at the possible entries by pressing the Range button.

8.1.3 Getting info about your NIC

Network Cards don't show up in RMVIEW or the Hardware manager. Instead there is another program which will list most NICs (all PCI and many ISA) it finds. It's \IBMINST\OS2SNIFF.EXE on Warp 4 and \IBMINST\CLBSNIFF.EXE on WSeB.

8.2 TCP/IP

8.2.1 MTU size

Adapting the MTU (maximum transfer units) size can increase your network's efficiency. If most of your file transfers are larger than 2KB you may want to increase it, since the default is 1500. To calculate the new size you have to add 40 to the desired packet size to account for the TCP/IP headers, i.e. 4136 for a packet size of 4096 (4KB). To prevent data loss also ensure that the number you specify doesn't exceed the maximum your network adapter allows. Ethernet adapters only allow a maximum of 1500!

To change the value either open your TCP/IP Configuration object, go to the Network tab, select a LAN interface and press Extended options. Now enter the new value in the Maximum transfer units (MTU) field. Or use the IFCONFIG command for the adapter in your TCP/IP SETUP.CMD file that resides in the \MPTN\BIN directory on your bootdrive, e.g. IFCONFIG lan1 mtu 4136 will set a packet size of 4KB.

8.2.2 Protection against synfloods

OS/2's TCP/IP also has protection mechanism against synfloods (aka "ping of death"). For TCP/IP 4.0x stacks you will need to apply the latest updates. After that you are presented with a new utility called SYNDEF.EXE. Enabling protection is as simple as issuing a SYNDEF ON command. Note that this does not turn the mechanism on permanently, so you'd better add the command to a script.

With TCP/IP 4.1 and later things are different, since the functionality is built into the stack itself and determined by the SYNATTACK parameter in your INETCFG.INI file. To get the current status issue the following command:


By default SYNATTACK is set to 0 (zero), i.e. protection is turned off. To turn it on you need to set it to 1 with the following commandline:


8.2.3 Route table

If you are using the 32-bit TCP/IP stack from TCP/IP 4.1 or later you may be experiencing problems with your route table filling up. This is caused by the new default keepalive value of 7800. The parameter is specified in seconds, so that equals 2 hours and 10 minutes! The old and more reasonable default was 60 seconds. To get it back create a file TCPEXIT.CMD in your \TCPIP\BIN directory and add a line INETCFG -S KEEPALIVE 60. Now your routes will only be kept around for a minute.

It's also a good idea to add -netmask to the default route in your \TCPIP\BIN\TCPEXIT.CMD or \TCPIP\BIN\B4TCP.CMD file which cuts down significantly on the run away routing table.

Do not add these customizations to your \MPTN\BIN\SETUP.CMD file since they may be discarded if you run the TCP/IP Configuration notebook later.

8.3 LAN Requester

The changes suggested in the following paragraphs have to be applied to parameters in the PROTOCOL.INI file that resides in the \IBMCOM directory on your boot drive.

If you have a Token Ring network the parameters XMITBUFS and XMITBUFSIZE are worth having a look at. Increasing XMITBUFS to 2 can enable greater throughput by allowing one buffer to fill while the other one is transmitting. By default XMITBUFSIZE is set to only support 2048 data packets and protocol headers. Increasing the setting to 4224 raises the limit to 4096. Note that this setting has to be euqal or greater the MTU size specified for TCP/IP.

Changing the timeout parameter T1 to 2000 (i.e. 2 seconds) reduces the number of retransmits across the network. If transmissions don't get a response within the time specified in this timeout value, they do multiple retires, resulting in additional network traffic.

You may also want to raise the Receiver Acknowledgement Timer parameter T2 to 400, i.e. 400 milliseconds. This setting reduces network session traffic by allowing a workstation time to respond without having to process retries.

The number of internal packets an adapter can use to send packets to itself instead of transmitting them to the network is specified by the LOOPPACKETS directive. You can reduce network traffic by increasing this number to e.g. 2.

The option NETBIOSRETRIES determines how often the LAN Requester will broadcast a request for duplicate NETBIOS names. If you have a reliable network you can reduce network traffic by decreasing the number of retries to 2.

Set NETBIOSTIMEOUT to 500. This parameter specifies in milliseconds how long LAN Requester will wait before sending the next request to identify a NETBIOS duplicate name. This change will speed up both startuptime and logon consideringly. You can calculate the startup time by multiplying NETBIOSRETRIES and NETBIOSTIMEOUT. The improvement for logon is even double the result.

Reducing RECVBUFSIZE to 256 will take better advantage of any unused portion of the 64KB NETBIOS segment.

8.4 NetWare Requester

Always ensure that you are using the latest version of the Novell NetWare Requester for OS/2. The latest (and final) is 2.12 and is freely available from IBM. There are some parameters that are relevant for performance that are hardcoded and have a less optimized value in older releases.

Check all machines in your network for the MTU sizes they support. Then adapt the clients to match the MTU size of the servers or to put it more plainly make all machines in your network use the maximum MTU size that is commonly possible.

That's it. I hope you were able to find some information you didn't already know and that your OS/2 system has gained some Warp factors of speed.

Christian Hennecke is a student of geography from Germany and has been working with OS/2 for five years now. Two years ago he started an OS/2 informational homepage that meanwhile also contains an extensive XFree86/OS2 section called "The X11-Files" as well as information about e.g. emulation on OS/2.

[Previous Page ] [ Index] [Next Page
VOICE Home Page: http://www.os2voice.org