Heath's Hints- by Heath Phillipi

Welcome back to Heath's Hints.

Last month we took a very general look at tuning your OS/2 Warp system. We saw how OS/2 uses the hardware in your PC, and what pieces could be upgraded to enhance the overall system performance. We also took a quick look at freeware utilities available on the Internet to help you in this task.

This month we will look at some quick and dirty little changes that can make a huge difference in the overall system speed of your PC.

Before changing anything in your CONFIG.SYS file it is a good idea to back up. If you aren't fortunate enough to own a tape backup (or one of those spiffy new Zip type disk drives) you are still in luck. OS/2 has a built in archiver that automatically saves all key system files and restores them for you (if ever needed).

To enable this feature simply right click on the desktop, choose settings and click the tab that says "Archive". Click the appropriate option and OS/2 will automatically keep a record of the last three successful boots of the system. To revert back to one of them simply press ALT-F1 when you see OS/2 and the white box in the top left of the screen during bootup. (Speaking of ALT-F key combinations on bootup, ALT-F2 allows you to see all the drivers that are loading as the system boots).

Now on to the juicy stuff. In order to verify that my advice works (it's always a good idea to verify your facts before blasting them out to the millions connected to the Internet) I did a clean install on a spare partition which I formatted with HPFS. The system I used consisted of a VLB/PCI motherboard with 256k L2 cache, 8 meg 70ns parity memory, an Adaptec 2842a VLB SCSI-II controller, HP 2490 SCSI-II HD, and a #9 Motion 531 VLB video card with 2 meg DRAM. The version of OS/2 I used was OS/2 Warp Connect Full Pack (TCP/IP support installed).

Before rebooting I installed the latest ATAPI fix since I use an IDE CD-ROM. After the initial boot I ran CSORTOS2 to order the CONFIG.SYS file so it would be easier to read and make changes to. Another added bonus is that it is easier to tell if newly installed apps change the CONFIG.SYS or add extra drivers that load at boot time (possibly causing the system to slow). A copy of the initial CONFIG.SYS can be seen by clicking here. I also installed DINFO so I could keep an eye on my swapper growth. For the first run of tests I used just the standard VGA driver.

Then I played with the system. The first thing I noticed was that the swapper grew to 9 meg just on bootup! As intimidating as this initial observation was, I trudged on. I set up the dialer for my local provider and went on-line. The first thing I did was download WebExplorer 1.03. After a quick reboot I went surfing.

Initial system response wasn't too bad. That is, until the swap file started growing again. After about fifteen minutes of browsing around and printing a few pages I noticed the swapper was shrinking. My first note was to see that the swapper had grown to around 20 meg at its maximum. Note two of this initial run was how badly printing was dragging the system down.

Not bad, all in all, for an initial run. I dug into the CONFIG.SYS and made a few quick changes in the following lines (I have numbered them so I may refer to them later, they should not have a number in your config.sys): 

1.  BASEDEV=PRINT01.SYS /IRQ
2.  PRINTMONBUFSIZE=1024,134,134

3.  SWAPPATH=G:\OS2\SYSTEM 2048 25600
4.  IFS=G:\OS2\HPFS.IFS /CACHE:512 /CRECL:4 /AUTOCHECK:DEG
5.  rem DISKCACHE=D,LW
6.  BUFFERS=60

7.  THREADS=150

8.  rem BASEDEV=IBM2FLPY.ADD
9.  rem BASEDEV=XDFLOPPY.FLT

10. MAXWAIT=2
11. SET HOSTNAME=HEATH
Lines 1 and 2 deal with printing. The additional /IRQ switch on line one switches the default printing method to direct IRQ access rather than POLLING (the default in Warp). Direct IRQ printing is much faster and has a lower overhead than POLLING, but you must make certain there are no IRQ conflicts between you LPT port and other devices (most notably your soundcard). POLLING can deal with conflicts, while direct IRQ can not. Line 2 just increases the default port buffer size to 1024 bytes (1k). The max is 2048 bytes or 2k.

Line 3 boosts the initial swap file size to 25600 (25 meg). The 2048 switch tells the system to warn the user when the swap file partition has only 2048 kb (2 megs) left for growth. Earlier I said that the swap file grew to 20 meg just from normal use. Since one of the biggest hits to performance is swapper size adjustment (growth particularly) I gave myself an extra 5 meg to play with. Line 4 drops my HPFS cache size to 512k from 1024k. I found out long ago that on memory tight systems diskcache is expendable. What use is a big diskcache if it means OS/2 is digging into the swap file more often?

Lines 5 and 6 deal with FAT. Line 5 is the cache statement for FAT partitions, which I rarely use or need so I REMed it out. Buffers is set to 90 by default, I drop it down to 60 on most of my systems. If you don't access FAT partitions at all, and you rarely use floppies (which are FAT) you can drop this even lower (to 6 or so). If you are using FAT partitions for OS/2 you would want to take an opposite approach. REM out the HPFS cache line (I have heard you can't REM this out. Anyone care to confirm?), up the DISKCACHE statement, and leave buffers at at least 90.

Lastly, when dealing with swap files, it is sometimes a good idea to play with the position of the swap file. IBM's official recommendation is:

For systems which have multiple partitions or multiple disks, this should be placed on the most used directory of the least used disk. Also, try to physically locate the swap file on the disk based on its usage. If you are doing a lot of swap activity, place the swap file at the start of the disk. If is it rarely used, place it at the end." - from the IBM tuning page.
It won't hurt anything to move it. Just remember to delete any old and unused SWAPPER.DAT files that you may leave lying around.

Line 7 reduces the number of threads that are available to the system. During my first run I used the GO utility to see how many threads were running (around 100) on a normal load. I added 50 for a safe margin.

Lines 8 and 9 have to do with unneeded drivers. The BASEDEV=IBM2FLPY.ADD line is for support of PS/2 floppies (which I don't have). Line 9 is to support the special floppy format used on disk distribution of Warp and other products. If you have a CD copy of OS/2 you will not need this line in day to day use. It is a good idea to just rem it out in case you may need it later.

Lines 10 and 11 are just little touches. Line 10 tells the system to give a process priority if it waits around for 2 seconds, while line 11 is strictly for the IAK (Internet Access Kit) dialer. If you don't have this line, and you dial your provider a second time in the same OS/2 session, you have to wait for the dialer to time out trying to find the host name.

Other changes to the system that I made initially were to install my video card specific drivers (I hate 640x480). I also turned off desktop animation by right clicking on the desktop, going into SYSTEM SETUP, SYSTEM, then the WINDOW tab.

Upon reboot I noticed something wonderful. My system was actually usable! Windows popped up quickly, WebExplorer was as responsive as any web browser in Windows on an 8 meg machine. Printing was still slow but it was bearable.

Still, not being one to ever say, "This is good enough," I started digging a little more. Another area that takes some playing to tune are your PATH statements. There are three path statements in your CONFIG.SYS. They each play a different role in how OS/2 finds files. They (and their purposes) are:

PATH
Like the DOS PATH variable, this is where OS/2 will look for executable files.
DPATH
Where OS/2 will look for data files.
LIBPATH
Where OS/2 will look for .DLL files (a period (.) means look in the current directory)
Finally, here some lists of drivers pertaining to DOS/Win support in OS/2 that you may be able to get rid of if you don't use DOS or Windows.

If you don't use DOS TCP/IP connectivity you can get rid of the following lines: 

DEVICE=G:\TCPIP\BIN\VDOSTCP.VDD
DEVICE=G:\TCPIP\BIN\VDOSTCP.SYS
RUN=G:\TCPIP\BIN\VDOSCTL.EXE
If you don't use DOS-Windows support at all you can dump these lines: 
FILES=20
BREAK=OFF
SHELL=G:\OS2\MDOS\COMMAND.COM G:\OS2\MDOS
FCBS=16,8
RMSIZE=640
DOS=LOW,NOUMB
DEVICE=G:\OS2\MDOS\VEMM.SYS
DEVICE=G:\OS2\MDOS\VXMS.SYS /UMB
DEVICE=G:\OS2\MDOS\VDPMI.SYS
DEVICE=G:\OS2\MDOS\VDPX.SYS
DEVICE=G:\OS2\MDOS\VWIN.SYS
DEVICE=G:\OS2\MDOS\VW32S.SYS
DEVICE=G:\OS2\MDOS\VCDROM.SYS
DEVICE=G:\OS2\MDOS\VMOUSE.SYS
DEVICE=G:\OS2\MDOS\VCOM.SYS
DEVICE=G:\OS2\MDOS\VVGA.SYS
Lastly, if you don't have a soundcard (or you wish to disable it) you can type DINSTSND.CMD in any OS/2 command session. This will disable sounds relating to the desktop.

Hopefully this will give you a good start in tuning your own system. OS/2 is a wonderful operating system if you take the time to learn how it works and how to use it. Fine tuning your own system helps you in both of these areas, plus it has the added bonus of increasing your system speed. And that's one thing we all want, isn't it?

Heath Phillippi is currently a Customer Engineer for AmeriData, Inc. in Appleton Wisconsin. He is the OS/2 Warp Champion for the OS/2 BESTeam, as well as a proud member of Team OS/2.

Send a letter to the editor.

Our Sponsors: [EmTec] [Mt. Baker] [ScheduPerformance] [Shenandoah] [SPG]

Back to Contents | ® Previous Article | Next Article ¯

This page is maintained by Falcon Networking. We welcome your suggestions.

Copyright © 1996 - Falcon Networking