REFTEST, Version 1.0 6/30/88 by Randy A. Scott


DESCRIPTION:
REFTEST will test your machine to determine the best RAM refresh time
for your computer and create a short .COM program to set the refresh
counter at this rate. This can result in a performance increase of 5
to 25%.


SYNTAX:
REFTEST T[filename] | Vn | Mn

T : Test to find optimum counter value
Tfilename : Logs results to named file
Vn : Tests using specific value n only
Mn : Makes QFRESH.COM using value n

"n" is a decimal integer value (1 to 65535), usually between 20 and
1024. "filename"'is any legal DOS filename; will overwrite existing
files.


BACKGROUND:
Dynamic RAM essentially acts like a tiny capacitor. Periodically, it
has to be "recharged", or refreshed, to retain its contents. All
PC's have a counter that keeps track of when this needs to be done.
When the counter counts down to zero, a refresh is triggered. This
counter is adjustable, and is defaults to a more or less arbitrary
number.

During the refresh cycle, the CPU is essentially suspended, so no
"work" gets done during a refresh. This is known as "overhead", and
usually eats up somewhere between 5 and 25% of your computer's
processing time.

Most RAM used in computers today doesn't need to be refreshed near as
often as the default specifies. By adjusting the counter value, you
can regain much of that lost overhead time.

The down side is that if you reduce the refresh rate too far, your
RAM will lose its charge before a refresh gets done, and some data
will be lost. This will invariably result in a PARITY CHECK error,
and you will have to reboot your computer. This has absolutely no
harmful effect on your computer! It just means that your RAM needs a
faster refresh rate.


OPERATION:
Run "REFTEST" alone for a brief description of the program. Then run
"REFTEST Tref.log" to start testing. (This will create "REF.LOG",
which will be a duplicate of what comes up on the screen.) Every 15
to 30 seconds, a line will appear that says,

Value : nnn Performance increase : xx%

Higher values represent a longer delay between refresh cycles, and
thus greater performance increases. (The test will actually start
with a refresh rate 6 times FASTER than the default, which will give
a (probably large) NEGATIVE performance increase).

Eventually, the percentage performance increase will level out, and
will not rise any higher. At this point, stop the program using
Control-C (it won't really stop until it finishes a test cycle).
Pick the LOWEST value that corresponds to the highest percentage
increase reached. This will usually be somewhere between 100 and
1000. This is the "n" value you want to use in the next step.

Now run "REFTEST Mn" where n is the lowest number that resulted in
the highest performance increase. This will create QFRESH.COM
optimized for your system, and will report the percentage increase it
provides. You should put QFRESH in your AUTOEXEC.BAT.


NOTES:
If you let "REFTEST T" run long enough, your system will eventually
crash with a parity error. Just cold-reboot. Take a look at the log
file to see where it died. If it died before the performance
increase leveled off, this will show the highest "n" value you can
get away with. If you take exception to your computer locking up
with a parity error in the middle of your work, running your machine
right on the ragged edge of the refresh cycle is probably not a great
idea.

Note that "n" can be any integer value, not just the ones that show
up during testing.

The default "n" value is 18. Values higher than this will speed up
your machine; values lower will slow it down. In some instances
this may be desirable: if you have a flakey RAM chip somewhere that
results in a PARITY CHECK even at the default refresh rate, you can
use a small value of "n"--between 1 and 17--and increase the refresh
cycle. This could get you through an important project until you
have time to isolate and replace the defective chip.

For some reason, some computers will crash with a "n" value of 1.

IMPORTANT NOTE: The parity error is your safety net when playing with
refresh cycles. If you get a PARITY CHECK, you've gone too far; if
not, you're OK. Unfortunately, not all IBM "compatibles" utilize
parity. A few less expensive clones--in particular, Tandy's lower-
end models, like the 1000's--don't.

The easiest way to tell if your computer uses parity checking is so
see how many RAM chips it takes to add a bank of RAM. If there are 9
chips per bank, you have parity; if there are only 8, you don't.

If your machine doesn't have parity, you could go past the allowable
refresh cycle time and not know it. Nothing would go wrong until you
happened to execute code that happened to reside at a RAM location
that needs a faster refresh. Then you will undoubtably get an abrupt
crash.

If you have one of these machines without parity, your best bet is to
thoroughly test the RAM at the new refresh rate you choose. There
are many RAM testing programs available; RAMTEST by Brown Bag
Software (look for RTEST203.ARC, 45K) is a good one. It is available
on The Drawing Board, 15/2, 505-525-0844; downloadable and file-
requestable.


TECHNICAL INFO:
Modifying the refresh cycle on a PC is really quite simple. Here is
the assembly source for QFRESH.COM, which is created by REFTEST:

MOV AL, 74
OUT 43, AL ; Tell timer to accept 2 byte value
MOV AL, ; is low order byte
OUT 41, AL
MOV AL, ; is high order byte
OUT 41, AL
INT 20 ; Exit to DOS


The motivation for this program comes from the July 1988 issue of PC
Magazine, which has an excellent discussion of RAM refresh cycles.
See it for further information.


----------------------------------------------------------------------------


I would be interested in hearing your results with this program,
especially if you get a performance improvement to of over 15%.
If you would like to let me know how it went, please send a
description of your system (type of computer, clock speed, amount of
memory, etc.) and a copy of the resulting REFTEST log file to me, or
upload it to The Drawing Board.

Send comments/suggestions/complaints to:

Randy A. Scott
Box 3702
Las Cruces, NM 88005

Or send Fidonet mail to:
Randy Scott
Sysop, The Drawing Board
Fidonet node number 15/2