Subject: dram -- bogoboost without patching!
From: Paul Gortmaker <[email-masked]>
Date: Thu, 1 Sep 1994 16:26:27 GMT
Newsgroups: comp.os.linux.announce

Some of you may remember the bogoboost patch -- a patch which
would change setup.S to alter the DRAM refresh timer before switching
to protected mode. The idea is that on older machines, you could get up to
a 5% performance increase by extending the period of the refresh
timer from the standard 15us. (Most newer machines implement a hidden 
or slow (120us) refresh in the BIOS setup menu, and hence already take 
advantage of this boost.)

	If you don't remember the bogoboost patch, then I have included
the README file after the LSM entry so you can get a better idea of
just what it is that is being discussed here.

	The scoop is that now you *don't* have to patch your kernel
to do the same thing! You can use this program --  "dram" -- to do
the job! That means you can put it into one of your /etc/rc files,
and have it set the refreh rate every time automatically. No patching,
no mess, no fuss. :-)

	There is a man page which contains most (but not all) of the 
information in the README file. The package is dram-1.00.tar.gz, which
will be temporarily in /pub/Linux/Incoming on sunsite, before moving
to /pub/Linux/system/Misc

Paul.
---------------------------------------------------------------------------
Paul Gortmaker - Department of Electronics Materials Engineering,
c/o The Research School of Physical Sciences and Engineering,
The Australian National University, Canberra ACT, 0020.
Ph (616) 249 0374  Fax: (616) 249 0511  E-mail: [email-masked]

Begin3
Title:          dram
Version:        1.00
Entered-date:   August 31, 1994
Description:    Small utility to set the DRAM refresh rate. This will give
		a small performance boost to slower machines that don't
		implement a hidden and/or long (120us) refresh in the BIOS
		configuration menu. Same functionality as the bogoboost
		patch, but *without* patching the kernel each time.
Keywords:       dram performance memory bogoboost refresh
Author:         [email-masked] (Paul Gortmaker)
Maintained-by:  [email-masked] (Paul Gortmaker)
Primary-site:   sunsite.unc.edu /pub/Linux/system/Misc
		14kB dram-1.00.tar.gz
Alternate-site: 
Original-site:  
Platform:       
Copying-policy: GPL
End

---------------------README from dram-1.00.tar.gz------------------------

This document describes the technique of changing the period of the
DRAM refresh timer for a minor performance gain. 

Most of this information is duplicated in the man page. See the file
./man/dram.8 for the raw nfoff, or ./man/dram.man for the preformatted
man page.

************************************************************************

WARNING:

	You are changing low level hardware parameters with this
	program, and can easily crash your system by giving it 
	a refresh period that is too long. (You will be warned by
	the  program too.)  I STRONGLY suggest going single user and 
	mounting all filesystems as read-only before experimenting.
	 
************************************************************************

See the file "COPYING" one directory up for details on copying, 
warranty, standard disclaimer, etc.

Paul Gortmaker.

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

In the beginning there was the XT. And it had crummy memory. The little
storage cells of the memory would quickly forget what they were trying
to remember. Your memory forgets what it is remembering unless you give 
it a jab (refresh) every so often. Because of the poor memory in those
days, the engineers chose a conservative value of one refresh every 15us
(microseconds) by default.

Now each megabyte of memory has almost 9.5 *million* of these cells.
You can imagine that it will eat up some of our computer's power
to read and re-write *all* these cells every 0.000015 seconds.
(A refresh cycle involves reading a value from memory, and then writing
it back to the memory cell again.)

Well, the basic design is the same in todays modern SIMM (Single
Inline Memory Module) but they can do much better than being able
to remember for a mere 15us. Todays DRAM (Dynamic Random Acess
Memory) chips on the common SIMM you have are capable of having
a refresh only once every 500 --> 1000 us or more. 

Some motherboards have a BIOS option "Slow Refresh", which
changes the refresh from 15us to a more reasonable value, like 120us.
This is *still* conservative, but better. And good motherboards
will have a "Hidden Refresh" option (or will silently implement
one) so that it hardly holds up the computer at all when it is
doing a refresh.

Even if your BIOS does *not* have this option, you can change the 
time period of the refresh timer with this simple Linux program.

You should know when you have exceeded a reasonable refresh time
for your memory, as you will get NMI's (Non Maskable Interrupts) which
will report "parity errors" meaning that your memory is starting to 
forget stuff. Parity is a 9th bit that is always set so that the sum of
the 8 bits of the data byte plus the ninth parity bit will *always*
be an even number. If the computer sees some memory in which the
sum is *not* an even number, then it knows the memory has changed
by itself, and reports a parity error. I would say that any time
used that is less than 1000us is "reasonably" safe.

Note that some el-cheapo systems use 8-bit DRAM, which means that
there is no parity bit. In this case, there is no safety-check against
memory corruption, and the operating system will proceed until the
memory corruption crashes the system. Some system BIOS setup programs
will allow you to either watch or ignore the parity bit -- this is to
allow these systems to use the (broken) 8-bit memory described above.
Make sure that the parity bit is enabled if you have ok DRAM/SIMM.

Note that there is no point in pushing the timer to the
brink of the parity error limit, because most of the gain is achieved
long before that. Consider the following data I took on an old
12MHz AT (286) computer (using the DOS version of my program).

DRAM refresh period(us)		Landmark v2.00 rating	    % increase
-----------------------		---------------------       ----------
	15				15.48			0
	120				16.14			4.26
	250				16.19			4.59
	500				16.21			4.72
	1000				16.22			4.78
	2000				16.22			4.78
	5000				16.23			4.84
	10000				16.23			4.84
	20000				16.23			4.84

(Note that at 10000 and 20000, the machine would eventually have a 
parity error as described above.) As can be seen from the above data,
we get about a 5% increase in speed with the *longest* refresh period,
and we had already obtained over 97% of the maximum possible increase
with a nice "safe" value of 500us.

On the other hand, if your motherboard is already (silently?) doing
a 120us, or hidden refresh, you may not even see a difference. Given
the above data, the difference between a 120us refresh, and the
longest refresh tested was only a mere 0.5%

Note to Cyrix DLC Users:
========================
Mind you, if you are one of the Cyrix DLC users, who *has* to enable
the BARB input, your speed increase *may* be more dramatic, and it
may *not* trail off so quicky either. You will have to experiment, and
find the best tradeoff between system stability and overall performance.

Summary:
--------
Changing the period of the refresh timer is an old trick used by the 
speed hungry since "way back" in the XT days, to get up to a 5% speed 
increase for free. If you are one of the Cyrix 486DLC users who *has*
to use the BARB input, you may stand to gain much more. 

Using the program:
------------------

        Since you are doing all sorts of low level I/O when using
this program, you must be root to read or write any of the configuration
parameters. If you do not have root priv. you will be told so, and
the program will exit.
 
Other than that, just pick a number based on what you read above, 
and type "dram 750" or whatever you decided on. If you want the program
to set the refresh rate at every boot, then decide on a final resting 
place (/sbin ?) for the program, and copy it there. Edit one of your 
startup files (/etc/rc.d/rc.local possibly?) and add the line

        /sbin/dram 750

Have fun,
Paul.

--
Send submissions for comp.os.linux.announce to: [email-masked]
Be sure to include Keywords: and a short description of your software.