VOICE Home Page: http://www.os2voice.org
[Previous Page] [Next Page]
[Features Index]
|
VOICE Home Page: http://www.os2voice.org |
[Previous Page] [Next Page] [Features Index] |
By Christian Hennecke ©September 2000 The OS/2 Files: http://www.os2world.com/os2files/ |
It's supercharging time again. This month we will have a look at video performance
and some GUI optimizations. And there is more! The last weeks saw several threads
in the newsgroups about problems people had with high CPU loads running DOS and
Win-OS/2 applications. The second part of this article therefore contains tips to
solve or workaround the problem and other general DOS/Win-OS/2 information.
This is also a call for help. Next month's article is to deal with printing and
networking. However, being a networking rookie, I don't know that much about optimizing
this part of OS/2. So if you know how to speed it up or increase functionality (e.g.
undocumented features) please contact me. I would also like to know something about
network printers that seem to be tricky to configure. Thanks!
This article is part of a series on improving your OS/2 system that is published
in the VOICE Newsletter. Last month's articles covered CD-ROM and harddrive performance,
responsiveness and stability issues and memory consumption. All the tips can be
viewed 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 June 2000 issue of the VOICE
Newsletter.
If you have a motherboard with an Intel CPU and chipset you won't need to read
this section any further since its BIOS will take care of activating all interesting
features for you. However, if you have an AMD K6-2 or K6-III CPU with CXT core read
on.
These processors offer features called write allocation and write combining.
They can speed up data transfer to the video memory and general memory write operations
consideringly, but they need to be turned on. Unfortunately, many BIOSes won't do
that for you and it has be done by a driver instead. To my knowledge this feature
is built into every Windows video driver, but for OS/2 Scitech Display Doctor is
the only one that is capable of doing so.
But you are not completely out of luck if you don't have SDD installed. Several
people have written small drivers to switch on the features. I recommened the free
package setup4k6 by Cornel Huth
that includes a nice tool that comes in very handy for calculating the parameters
that have to be passed to the driver. The problem is that you have to specify the
starting address of your video card's frame buffer. I was told that it's easy to
find it for any Matrox card, since the Matrox driver's settings tool displays it
as Board mapping on the Information tab. Wrong! Do not use
that value.
Get the free tool DIVETEST
instead. Start it, go to the DIVE tab and press Query Caps. Now you
should be able to see the required address in the Starts at: field below
the Get Framebuffer Information line. Use this address to calculate the required
parameters. Doing so increased DIVE-marks for my G400 in Sysbench from 80.613 to
117.665 which is the same value that can be achieved with SDD. There is still one
caveat: Do not activate EnDIVE, otherwise you will see a performance hit. But since
EnDIVE implementations don't work correctly for most video cards anyway, you probably
won't loose any features.
Remember that mouse pointers are bitmaps, too. So depending on the pointer's
style and size different amounts of memory are used. The best is to stick to the
default black and white pointers. This will also prevent slowdown and flickering
that occur with DIVE programs otherwise. Also turn off the comet cursor since it
consumes additional memory and processing power.
Turning off the Desktop animation will also improve your video speed. Do a right-click
on the Desktop to bring up the Desktop menu, and select System Setup. Find
the System icon and double-click on it. Now click on the Window tab,
and disable the animation feature.
Another tip regards the pop-up menu you see when you do a right-click with your
mouse. If you know how to move, copy, create a shadow, find, etc., then seeing these
options quickly becomes an annoyance. To get rid of these redundant items in Warp
3, add the line SET MENUSTYLE=SHORT to your
CONFIG.SYS file and reboot or use XFolder's features to display only the
items you want. If you have Warp 4 open the System object, go to the Menu
tab and select short menus. There you can also de-select menu bars for
folders to save some screen space since all items are included in the context
menu anyway.
When you apply changes to a folder's content the system will automatically update
the folder view. This can take some time if you have folders with lots of objects,
especially if the option Always maintain sort order is activated or/and you
are using detailed view. By adding the line SET AUTOREFRESHFOLDERS=NO
to your CONFIG.SYS this feature can be turned off. Note however that you
will have to close and re-open the folder or select Refresh now from the
folder's context menu to have the folder reflect the changes.
Windows software doesn't need EMS memory to run. So you can safely decrease EMS_MEMORY_LIMIT
to zero and set EMS_FRAME_LOCATION to NONE. Turning off EMS support
saves a small amount of RAM.
When one uses separate, sessions a complete Win-OS/2 environment is started
for each session. Of course memory consumption is much higher than with shared
sessions. On the other hand a crash of one Win-OS/2 program won't lead to
the others in the same session following and crashing, too. In addition you can
specify different settings for each of the separate sessions. This way it is possible
to run programs that require mutually exclusive settings at the same time.
Font management has been kept separate for OS/2 and Win-OS/2. So fonts that are
registered to both systems are loaded again for every Win-OS/2 session and consume
additional memory. On the other hand this offers the opportunity of installing only
those fonts that are needed.
The Win-OS/2 settings also contain a WIN_ATM option that determines
if the Adobe Type1 Font Manager (ATM) and thereby Adobe Type1 fonts will be available
to a session. If WIN_ATM is set to ON, ATM and all registered
Adobe Type1 fonts will be loaded upon start of the Win-OS/2 session. This is done
again for each separate session! So if you e.g. use Aldus Pagemaker for DTP,
a good idea is to only register additional Adobe Type1 fonts and to de-activate
ATM for all programs that don't need the fonts, thus reducing memory footprint.
So what can be done about it? Well, this is a bit complicated since there are
several methods and each one does work only with some applications. Some things
can be adjusted by the session's settings.
There are two connected options called IDLE_SECONDS and IDLE_SENSITIVITY.
After a program issues a request for input, OS/2 waits IDLE_SECONDS before
it begins idle time detection. The standard value is zero, i.e. detection begins
immediately. The second option specifies a threshold OS/2 uses to determine if a
program is idle or not. If the application polls with a higher frequency than specified
(in percent) OS/2 will consider it idle, reduce its CPU time and give it to other
programs. So by lowering the threshold you should be able to take away some unused
CPU time from polling applications.
You can also apply some brute force by setting DOS_BACKGROUND_EXECUTION
to OFF. Now, as soon as you take focus away from the offending application
and switch to another it is stopped and will only receive CPU time if brought to
the foreground again. Of course it won't be able to do calculations for you in the
background this way and the problem with taking away resources from background processes
while the application is in the foreground still persist.
If the above doesn't work for you there is still some hope. Some people have
written TSRs that can release CPU time from the session they run in. They are loaded
by adding them to your AUTOEXEC.BAT file. Hobbes'
/pub/dos directory and Peter
Norloff's OS/2 BBS hold several of these helpers. Most have been written only
for a specific application, but the ones called OS/2
Time Slice Releaser (OSTSR), F4_35_CA
and TAME provide general
services.
OSTSR only is of use for programs that are aware of DesqView, an old DOS multitasking
extension software. OSTSR works by fooling DesqView-aware programs into thinking
that they are running under Desqview. When such a program makes a request to return
the rest of its timeslice to Desqview, the call is intercepted by OSTSR and is turned
into a similar request to OS/2. You can specify the amount of CPU time that's released.
Try using OSTSR 8. OSTSR is freeware.
F4_35_CA is a freeware tool by Veit Kannegieser. Try adding it to your AUTOEXEC.BAT
file and start a DOS or Win-OS/2 application. If the scrolllock LED is turned on
F4_35_CA can free some CPU time. See the accompanied file entpack.eng for documentation.
TAME does something different and is more like the OS/2 scheduler itself. It
monitors the activity of a program running in its session. Upon detection of idle
time, it releases CPU time to other sessions. Additionally, the next time its session
gets CPU it will be less tolerant. TAME has lots of options, also containing some
that can help to to determine the best settings. Documenting this is far beyond
the scope of this article. You may however want to try invoking TAME by adding TAME /TINY /I 9 /TS OS/2 to your AUTOEXEC.BAT
file. According to the documentation TAME is shareware (US$20). The last version
I was able to find was 3.33 (the 3.34 I found contained the same files) from 1996,
so I don't know if it still can be registered.
The programs can be used together. Also remember that you can specify different
startup files for sessions using the DOS_AUTOEXEC option if you need different
parameters for OSTSR or TAME.
That's it for now. Next month we will close the series with an article about
printing and networking. Again: If you have any hints on optimizing networking on
OS/2 please drop me a note.