VOICE Home Page: http://www.os2voice.org |
[Previous Page] [Next Page] [Features Index] |
By Christian Hennecke ©October 2000 The OS/2 Files: http://www.os2world.com/os2files/ |
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.
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.
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.
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.
Please note that all changes made to your TCP/IP, MPTS, LAN requester etc. configuration
require a reboot to become active.
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.
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.
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.
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.
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:
INETCFG -G SYNATTACK
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:
INETCFG -S SYNATTACK 1
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 255.255.255.0 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.
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.
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.