How to Supercharge OS/2 Warp -
Part 1

Introduction

When you install OS/2 a lot of default settings are used. IBM has chosen them in
way that allows stable operation on the maximum number of different systems. While
OS/2 usually works well as intended with the default settings there is much room
to adapt your OS/2 system to your personal needs and your specific machine setup.
This will probably result in dramatic performance gains.

A series of articles with tips on how to improve your system will be published
in the VOICE Newsletter. This month we look at tuning drives under OS/2 Warp. We
cover both CD-ROM and hard drives. All the tips can be viewed at my homepage at
http://home.foni.net/~chennecke/index_e.html
by selecting the tuning link.

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. So don't blame me if you end up with something unusable!

Credits

The information presented here has been gathered from several resources. Much
has been (sometimes literally) taken from Richard Oliver Kut's "How to Supercharge
OS/2 Warp" document from 1996. I would also like to thank IBM for their document
called "OS/2 Warp 4 Capacity Planning and Performance Tuning Guide" that
proved to be very helpful and contains even more detailed information. Also my personal
experience from fiddling around with several settings found its way here. Many hints
come from all the people in the OS/2 Usenet groups. Another valuable source was
the "OS/2 Warp 4 Kompendium" by Olaf Koch.

1. CD-ROM drives

If you want to speed up the response time of your CD-ROM drive, one way is to
make the RAM cache for it a bit larger. In your CONFIG.SYS file, find the
line that looks like IFS=C:\OS2\BOOT\CDFS.IFS
and rewrite it at the end to say e.g.

IFS=C:\OS2\BOOT\CDFS.IFS /C:4

and then reboot. What this does is change the default setting (/C:2) of 128 K
RAM cache to 256 K. Having the bigger cache will hopefully speed up the response
of your CD drive. Note, however, that you are stealing 128 K of RAM from OS/2, so
this might not be the best thing to do on machines with 8 MB of RAM or less.

If you like to experiment a bit, try changing the maximum number of sectors that
are read during a read access operation by specifying for example:

IFS=C:\OS2\BOOT\CDFS.IFS /C:4 /M:6

This will decrease the number of sectors to 6. The default is 8 sectors (/M:8).
The result is very likely to depend on the dominating filesize on your CD.

The last tip for CD-ROM drives is to enable Joliet support. Joliet is an extension
to the ISO9660 CD filesystem standard by Microsoft. It adds support for Unicode
and the use of filenames that can be longer than 32 characters and in mixed case.
This feature has been added by fixpaks to both Warp 3 and Warp 4 (from
FP#4 on). To turn it on add a /W switch to your CDFS line, like in

IFS=C:\OS2\BOOT\CDFS.IFS /C:4 /W

2. Hard drives

Your hard drive is an important part of the overall performance of your OS/2
system. Setting it up properly at the start will yield amazing results. The best
thing you can do to improve the performance of your existing hard drive is to format
it with the High Performance File System, or HPFS for short. This file system replaces
the standard File Allocation Table, or FAT system found on all DOS computers today.
HPFS has many advantages and improvements over FAT, and is ideally suited for OS/2.
The only drawback is that HPFS requires between 200 and 400 K of working memory,
plus the amount used for the cache. Therefore, using HPFS on anything less than
a 6 meg machine is counterproductive. Please note that if your hard drive size is
80 meg or less, that you will not see any measurable performance gain in speed,
but you will still have the benefit of resistance to file fragmentation, increased
data security, and a smaller cluster size compared to FAT, that will waste less
space on your drive.

2.1 Swapping

Choosing the appropriate location and size of your swapfile can improve system
performance drastically.
Upon startup OS/2 creates a swapfile with a given size or uses an existing one that
fits the parameters. Now if OS/2 runs out of physical memory, swapping occurs. When
the needed space exceeds the swapfile's current size OS/2 enlarges the file. Later
when the allocated space isn't needed any more the swapfile is reduced in size again
with the initial size as a minimum. The process of enlarging and shrinking the file
takes time, especially as some internal structures have to be created and maintained.
Additionally it can lead to fragmentation and hence to a slowdown of swapping operations.
If the file has the right size initially, no enlarging or shrinking will occur.

Most of the time a swapfile size of 20MB will be enough. Make it 32MB if you're
using VoiceType. This is a rule of thumb. To better adjust the size to your specific
system first choose a small initial size. Then create your typical working environment
by opening regularly used programs with files of the usual size. Now take a look
at the SWAPPER.DAT file's new size. Add a bit to the current value and
use that value as new initial size. However I wouldn't recommend using less than
10MB.
The default location for the swapfile is in the \OS2\SYSTEM directory on
your bootdrive. If you have only one harddisk place the swapfile in the root directory
of the most used partition so the harddrive's read/write head will be near it most
of the time. If you happen to have more than one harddisk place the swapfile in
the most used partition on the least used harddisk. This should increase performance
up to dramatically, especially on SCSI systems.

The corresponding CONFIG.SYS statement is

SWAPPATH=location threshold initial_size

For example

SWAPPATH=H:\ 2048 20480

would place the 20MB large file SWAPPER.DAT in the root directory of
the H: partition with a warning threshold of 2MB. If the free diskspace on H: sinks
below 2MB a warning message will be issued.

2.2 Cache

If you are running a HPFS formatted drive, try changing the IFS= line
of your CONFIG.SYS file to read something like:

IFS=C:\OS2\HPFS.IFS /CACHE:2048 /CRECL:64 /AUTOCHECK:C

The /CACHE:2048 parameter will reserve 2048K
for use by the cache only, so be careful how big you make this number. 2048 is the
maximum, and less than 512 is equally useless. If you have an 8 MB RAM machine,
start off with 512 and work your way up from there. On an 8 meg machine it will
be a balancing act between speeding up your drive and slowing down OS/2, so keep
an eye on how much crunching your hard disk does, and how long it takes to access
frequently used items. Somewhere in the above mentioned range will be a happy compromise.
See the table below for recommended cache sizes dependent on RAM and used file systems.

Recommended cache sizes

RAM

HPFS and FAT

HPFS only

FAT only

6-8MB

256 each

512

512

8-12MB

up to 512 each

up to 1024

up to 1024

12-16MB

512 each

1024

1024

16-20MB

up to 1024 each

up to 2048

up to 2048

20-32MB

1024 each

2048

2048

>32MB

up to 2048 each

2048

2048

The /CRECL:64 parameter sets the maximum
record size for caching. If most of your files are about 64K in size, then setting
it to 64 would be ideal. You can experiment with this number by adjusting it in
2 K increments, from a minimum of 4 (default) up to a maximum of 64. A good starting
point is 32. The /AUTOCHECK parameter determines
which partitions will be automatically checked if the system hasn't been shut down
properly.

Another trick to speed up HPFS systems is to specify some additional parameters
for the CACHE.EXE program, which regulates all the activity taking place
in the cache. Try adding the following line to the end of your CONFIG.SYS
file:

This will increase the time data is held on the cache. You may even try larger values
like /MAXAGE:60000 /DISKIDLE:60000 /BUFFERIDLE:30000.
This will hold data up to 60 seconds in the cache, but increase the risk of data
loss in case of a crash as well. Okay, now reboot and see if it makes any difference
on your machine.

Most people will also have FAT partitions on their system, e.g. for DOS or Windows.
You can specify a separate FAT cache with the DISKCACHE= statement in CONFIG.SYS:

DISKCACHE=1024,32,LW,AC:C

would set a cache size of 1024K, a record size of 32K (see above), turn on the
lazywriter and select the C: partition for autochecking. See the table above for
recommended cache sizes. If you don't access FAT partitions that much you may want
to lower the FAT cache in favour of the HPFS cache. Don't remove the statement completely
if you want to access floppy disks!

2.3 Searchpaths

When you start a program without a qualified path, i.e. you simply type something
like netscape.exe at the commandline, all the directories contained in
your PATH statement in CONFIG.SYS will be searched in the statement's
order. The same happens with DLLs that are called by a program only that this time
the LIBPATH is searched. As a result programs with paths at the end of
the PATH statement will take longer to start. Also note that some programs
have the bad habit oft inserting their directory at the statement's beginning upon
installation. By sorting these statements to reflect how often files are accessed
an often noticeable speedup can be achieved. Be warned however that this can cause
conflicts if you have several files with the same name and OS/2 or a program suddenly
can't find the correct files any more.
As some applications like compilers or databases cause heavy disk activity, but
also are not frequently used there will be a conflict of interest in granting them
the fastest search possible and slowing down other software. A good idea is to optimize
the path for the more frequently used software and setup some scripts that can temporarily
change the environment variables for the more seldom used applications. By specifying
the reserved environment variables BEGINLIBATH and ENDLIBPATH
you can add new directories to the LIBPATH statement's beginning and end.
Have a look at the following example with the original LIBPATH statement:

LIBPATH=.;C:\OS2;C:\OS2\DLL

This gets changed by issuing

SET BEGINLIBPATH=D:\IBMCPP\DLL
SET ENDLIBPATH=E:\UTILS

which leads to the new search order:

LIBPATH=D:\IBMCPP\DLL;.;C:\OS2;C:\OS2\DLL;E:\UTILS

that can be changed again. Note that the changed environment is only valid for
the session of CMD.EXE in that the script was executed. However, if you start a
new session from there the environment will be inherited.
The PATH can be changed by specifying something like:

SET PATH=x:\newfirstpath;%PATH%;x:\newlastpath

%PATH% will access the current path's value. Another way of optimization
would be to use several CONFIG.SYS files containing different path statements,
but then a reboot will be necessary each time you want to change the environment.
(This will be explained later in the series.)

2.4 Drivers

IBM's IDE driver IBM1S506.ADD doesn't support the latest chipsets by VIA, Aladdin,
AMD etc. You can speed up your system significantly by using the freely available
IDE driver DANIS506.ADD
by Daniela Engert. Read the documentation thoroughly as there are several options
that can speed up your system or cause it to crash!

Also there are some extra vendor specific drivers available for older chipsets
that can enable special features.
Later IBM1S506
drivers have busmastering enabled by default. Try the /!BM switch to
turn it off if you are experiencing problems.

Well, that's it for this month. Now you can make yourself a pot of coffee or
tea and start to loosen your system's brakes. I hope you will see OS/2 engaging
Warp speed.
Next month we will try to improve your OS/2 system's responsiveness and stability.

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.