Inside SoftRAM 95

Our authors examine "RAM doubling" technology, then look inside SoftRAM 95 to find out what it does and, more importantly, does not do.


August 01, 1996
URL:http://www.drdobbs.com/parallel/rapidmind-c-meets-multicore/parallel/inside-softram-95/184409937

The slogan "Double click. Double Memory" was at the heart of one of the most successful advertising campaigns in the history of PC software. In May of 1995, Syncronys Softcorp rolled out a software package called "SoftRAM for Windows 3.1" for users frustrated by "out of memory" errors and other resource limitations. Six months and a Windows 95 version later, Syncronys reported net revenues of $11 million for the third quarter of 1995, based almost entirely on SoftRAM sales of 650,000 units. SoftRAM coasted into the new year as one of the top three best-selling software products of 1995, up there with the likes of the Windows 95 Upgrade.

After a summer of extremely strong sales, however, speculation began building that SoftRAM wasn't doing what Syncronys claimed. Toward the end of October, several independent sources (including one of the authors, Mark Russinovich) examined the internals of the software to find out the extent of RAM doubling underneath the pretty dials that SoftRAM presents to both Windows 3.x or Windows 95 users. About the same time, Syncronys issued a press release announcing that in the Windows 95 version "RAM compression is not being delivered to the operating system."

About then, mainstream media began to pick up the controversy, with articles appearing in PC Magazine, PC Week, Houston Chronicle, Washington Post, and Time magazine. In early 1996, Syncronys stock dropped to a fraction of its heights and the company faced numerous class-action and stock-holder lawsuits, as well as rumored pressure of inquiries by the Securities and Exchange Commission and the Federal Trade Commission. In addition, while Syncronys still states that the Windows 3.x version delivers everything it claims, an upgrade that promises to correct the admittedly broken Windows 95 version is overdue.

In this article, we'll present an introduction to the RAM-doubling technology used by, and claimed by, SoftRAM, followed by a brief tour of SoftRAM 95 internals. We'll include a program that can be used to detect whether a popular technique of RAM doubling, called "RAM compression," is taking place (available electronically).

RAM-Doubling Technology

Syncronys claims that SoftRAM uses two techniques to increase usable memory. The first technique involves overcoming a flaw in how Windows 3.1 allocates memory. Specifically, when users encounter a message related to insufficient memory, it is usually because the system has allocated most, or all, of the critical memory that resides in the first 1 MB of the PC. This memory, known as "conventional memory," is where Windows allocates a program segment prefix (PSP) data structure for every Windows program it starts. When this memory runs out, no more programs can be run. Unfortunately, Windows also uses this memory as space to load device drivers and fixed memory DLLs (fixed means that the code is RAM resident at all times and never paged to disk) that can be loaded just as easily into memory above the 1-MB boundary. Memory can needlessly disappear quickly. Windows can be prevented from placing drivers in the low, 1-MB region, thus providing more space for user applications, by fragmenting the memory into pieces that are too small to be used for DLLs and drivers. Other methods can also prevent programs from being loaded there. Every memory-enhancement product sold for Windows 3.1 does some form of this.

The second technique for increasing usable memory is RAM compression. To understand the goal of this performance-enhancement method, you must understand the behavior of demand paged virtual-memory systems such as those present in Windows 3.x and Windows 95. Modern operating systems provide applications with the illusion that they are running on computers with much more physical RAM than actually exists. When physical memory is exhausted, the OS moves information that's unlikely to be used to a disk file known as a "paging" (or swap) file (pagefile). The system can then load additional programs or data into the space that has been freed in physical memory. Whenever a program attempts to access code or data that has been moved to disk, it triggers a page fault, which is an exception condition that the operating system transparently handles by exchanging the requested data on disk with other data in memory. The act of moving data from a paging file into memory is called a "swap-in" or "pagefile read," while writing data to the paging file is a "swap-out" or "pagefile write." Thus, the name "demand paged virtual memory" comes from the fact that memory that has been swapped-out is swapped-in when it is demanded by an application, and that the data stored in a swap file is in virtual memory.

RAM compression assumes that the pagefile can be cached in compressed form in physical memory in order to reduce disk accesses and thereby increase performance. The presence of this type of cache has several effects that combine to determine whether it yields an improvement in overall performance. Figure 1 shows the memory-access pattern of a typical Windows application. The graph shows how many page faults occur when an application is given varying amounts of memory. The value of the curve at 8 MB, for instance, indicates how many page faults (and therefore disk accesses) are generated when running the application on an 8-MB machine. When memory is allocated for a compressed pagefile cache, applications executing on the machine have less memory to work with and, therefore, generate page faults as if they were executing on a smaller machine.


Figure 1: Typical Windows application memory-access profile.

Figure 2 shows that, for a 2-MB cache, the number of page faults is determined by the value of the curve at 6 MB. Whenever there is a page fault, Windows determines where the page should be fetched from. This results in a disruption of the currently executing application and is the first effect of a compressed pagefile cache-the overhead of cache-induced page faults.


Figure 2: Effect of compressed RAM cache.

A typical RAM compressor compresses all or most of the data that is sent from Windows to the swap file, so the page-fault rate at the effective (reduced) memory size determines the number of pages that will be compressed and decompressed. This is the second effect of a compressed pagefile cache-the overhead of compression and decompression, increasing the overall execution time.

The compressed pagefile cache creates an intermediate region on the graph that extends from the effective memory size (6 MB in Figure 2) to a point to the right of the physical-memory point that is related to the compression ratio obtained on the data being paged. In the example, the compression ratio is an optimistic 3:1, so the 2 MB allocated for the cache creates a cache region that is 6 MB in size and that extends to the 12-MB point on the graph.

The third effect introduced by the compressed pagefile cache is that any accesses that land in the region defined by the area between the physical-memory size of the machine and the right side of the cache region would have resulted in disk I/O in the absence of the cache, but because these accesses land in the cache, this I/O is avoided. So, the third effect is avoided pagefile reads and writes, decreasing overall execution time.

This description is simplified since there are other secondary effects, such as the effect on the size of the disk cache, but the general approach should be clear. A basic rule must be satisfied for RAM compression to be effective: Time saved due to avoided disk I/O must be greater than overhead incurred by cache-induced page faults, plus overhead of compression and decompression.

While this seems an easy relationship to satisfy, more-complex models based on real-world performance parameters and access patterns indicate that it is, in reality, very difficult to obtain a performance boost with this method. In fact, benchmarks of popular memory-enhancement software (those that actually perform RAM compression) show major performance degradations when running typical Windows applications.

The final technique, which Syncronys does not advertise, is actually a trick users can perform from the control panel to increase the size of the paging file. Since the total memory that can be allocated at any given time is equal to the sum of the size of physical RAM and the size of the swap file, more memory can be allocated with a larger swap file. Windows 95 dynamically resizes the swap file to accommodate the needs of the applications that are executing, but Windows 3.x does not have this level of sophistication. Under Windows 3.1 you have two choices for the type of pagefile that can be used: a permanent swap file that is created with fixed size, or a temporary swap file that is dynamically created each time Windows runs, but can grow during a session. The advantage of a permanent swap file is that Windows can access it very efficiently using low-level disk I/O since it knows exactly where the swap file lies on disk. The drawback is that, since it is of fixed size, large applications can potentially run out of memory. The advantage of a temporary swap file is that it can grow to some extent, but the drawback is that, under Windows 3.1, accessing it requires going through the slow DOS disk I/O facilities. (Note that under Windows For Workgroups 3.11, DOS disk I/O is faster, so there is no disadvantage to having a temporary swap file.)

When a temporary swap file is in effect, Windows 3.x by default allows it to grow only to a size equal to four times the amount of physical memory present on the machine (for example, on a 4-MB machine the maximum swap-file size would be 16 MB). This default can be overridden by any user, however, by placing the line PageFileOverCommit=X in the [386Enh] section of the system.ini file, where the value X is the multiplier that replaces the default value of 4. Since many users are unaware of the size restriction for temporary swap files, most RAM doublers modify the overcommit value for them in order to allow larger applications to run.

The three techniques for enhancing memory are controlling 1-MB memory usage, RAM compression, and resizing the swap file. SoftRAM's most vocal claim is that it performs RAM compression.

Inside SoftRAM 95: The Windows 95 Version

We'll start by describing the functionality of the Windows 95 version of SoftRAM in spite of the fact that, in October 1995, the company admitted it doesn't work. It may seem unnecessary to go to this trouble, but it turns out that the reason that the Windows 95 version of SoftRAM does not deliver compression is not just the result of a minor bug. Analysis indicates that SoftRAM 95 does try to create a pagefile cache, though one that is uncompressed.

The first thing to note about the Windows 95 version of SoftRAM is that, under Windows 95, the pagefile-sizing limitations, and the conventional memory-allocation bottleneck are effectively gone. Further, the resource-heap size limitations of Windows 3.x are also a thing of the past. Out of the RAM-doubling techniques claimed by SoftRAM, that leaves just RAM compression as a Windows 95 memory enhancement possibility.

The Windows 95 version of SoftRAM is based on the Microsoft Device Driver Kit's (DDK) Dynapage example (see DDK \BASE\SAMPLES\DYNAPAGE) pagefile device. This device driver takes pagefile read and write requests and creates the appropriate disk I/O requests. When SoftRAM is loaded during Windows start-up, the first thing it attempts to do is allocate a buffer for its cache. The default size of this buffer, as determined by the SoftRAM MaxPhys parameter created in the system.ini file, is 100 percent of the memory that Windows reports to it as free. Windows will not let all this memory be allocated in one try at that time, so the memory allocation specified by the default will always fail. From that point on, SoftRAM turns off its code, and only the Microsoft dynapage code within it remains active. This is the behavior that users will get unless they modify SoftRAM's default configuration.

If the SoftRAM MaxPhys parameter is lowered by users to a point where the allocation succeeds, SoftRAM actually does manage a pagefile cache. Data that would normally go to the swap file stops in this cache, and conversely, when data is read from the swap file it also ends up in this cache. However, the data in the cache is not compressed. Moreover, thorough disassembly reveals the presence of code that manages pseudocompressed pages. At idle time, SoftRAM goes through the area of the cache containing non-pseudocompressed pages and copies them to another area of the cache, attaching a 3-byte header containing only one piece of information that is used-the size of the header! It is clear that while the author of the code may have at some point intended to put in a compression routine instead of this pseudocompression, no such routine exists.

Lack of any compression code was not the reason that Syncronys announced that the Windows 95 version of SoftRAM was defective, however. Rather, the code contains the severe problem of corrupting data structures when reentrancy occurs. If you have ever written a multithreaded program where several threads must access shared variables, then you have an idea of the nature of this problem. SoftRAM can be servicing a pagefile request with one thread, which issues a disk I/O request and then waits for its completion. While the first thread is waiting, Windows 95 can schedule another thread that also generates a pagefile request. This second request to SoftRAM's code, while one request is not completed, can cause SoftRAM to become confused about the state of its internal buffers. This can then lead to application data becoming scrambled in the SoftRAM cache: Pretty soon, applications start reporting errors, and not long after, a crash of the system results.

This problem is typically solved by incorporating locks into the code so that only one thread can access shared data structures at a time. Because this flaw in SoftRAM is exercised only when there are several threads running, it normally won't show up unless there are multiple applications executing and active at the same time. An easy way to trigger it is to start a compile, then during the compile, switch to a word processor and start a search operation. As long as enough memory is being used so that paging takes place, SoftRAM will cause data corruption. It is most likely the ease with which SoftRAM causes system crashes that forced Syncronys to issue its press release.

From looking at a disassembly, it also appears that SoftRAM was probably one of its author's first assembly-language programs. For example, the programmer seemed to lose track of the global variables that were allocated because fully one fifth of the SoftRAM global variables are written to, but never read. In addition, all the buffer-copy routines are terribly inefficient. Compare the copy routine, taken from the SoftRAM code, in Example 1(a), with its efficient counterpart, similar to what you'll find in any beginning assembly-language book, in Example 1(b).

(a)

 mov edx, source
 mov eax, dest
 mov ecx, 4096/4 ;      size of a page on x86 processors / 4
copyloop:
 mov ebx, [edx] ;      read source double word (4 bytes)
 mov [eax], ebx ;      write destination
 inc edx ;     increment source pointer by 4 bytes
 inc edx
 inc edx
 inc edx
 inc eax ;     increment destination pointer by 4 bytes
 inc eax
 inc eax
 inc eax
 loopd copyloop ;      decrement ecx and loop until its zero
 ;                (1024 times in this case)

(b)

 mov esi, source
 mov edi, dest
 mov ecx, 4096/4
 rep movsd ;      buffer move operation -
;     repeated 1024 times since operation
 ;      moves 4 bytes at a time
 

Example 1: (a) Copy routine from SoftRAM 95 (Windows 95 version); (b) efficient copy routine.

The UI of the Windows 95 version of SoftRAM indicates that the software has created an amount of memory equal to the physical-memory size of the machine (SoftRAM), while preserving the original memory (HardRAM). Moreover, these same values are presented regardless of whether or not SoftRAM's system-level code is loaded, and whether or not SoftRAM's buffer allocation succeeds. SoftRAM does not compress memory, so the only effect it has is to increase paging of applications by reducing the memory available to them and in no case increases the total amount of available memory.

Inside SoftRAM 95: The Windows 3.1 Version

The internals of the Windows 3.1 version of SoftRAM are probably more interesting than the Windows 95 version because Syncronys still claims that it expands system resources, clears critical 1-MB bottlenecks, and doubles system memory using "patent-pending compression" achieving up to "5 compression ratios." The Windows 3.1 version has four components: the SR-START.EXE program that runs and then exits when Windows boots, a UI called SR95UI.EXE that displays the dials, and two drivers, PAGEFILE1.386 and PAGEFILE2.386, that replace the native Windows drivers that handle pagefile I/O.

Examining the UI, which displays the difference in resource usage as it would exist without SoftRAM versus actual resource usage, shows that the numbers presented by SoftRAM are indeed, in Syncronys's words, "a projection." To arrive at the figures, SoftRAM queries Windows for the resource usage, and then subtracts a small constant from the value it obtains. The original value is displayed as the SoftRAM resource number and the downward adjusted number as the resource usage that would occur without SoftRAM. When asked about this, Syncronys claimed that the numbers are a projection, and that what SoftRAM does can lead to slightly different results. Disassembly and analysis of the various SoftRAM components show that there is no code that deals with resource usage. In addition, experiments verify that SoftRAM does not affect resource availability.

The next claim is that SoftRAM clears critical 1-MB bottlenecks. This is one of the two places where SoftRAM actually does more than just project the numbers. Instead, SoftRAM uses code from a March 1995 PC Magazine utility, IBMFORT, that implements the memory-enhancement technique of fragmenting conventional memory, in an attempt to make Windows allocate it more effectively._The implementation is effective only under specific conditions, and at the time SoftRAM performs the fragmentation, Windows has already loaded device drivers and system DLLs that may have grabbed much of the precious 1-MB memory. Thus, only a fraction of the potential gains are realized.

Finally, the claim that SoftRAM performs RAM compression can be verified through analysis of the two drivers, SOFTRAM 1.386 and SOFTRAM 2.386. Disassembly and comparison with the corresponding sample drivers upon which they are based (included in Microsoft's DDK) leaves little differing code. What is left after the Microsoft code is removed is some initialization related to SoftRAM's system.ini settings, and a "mystery" routine of some 3000 bytes in length.

The mystery block of code is structured much as a compression algorithm might be structured, but the code is never executed. Static analysis of the drivers indicates that there are no control transfers made to the block of code from anywhere else in SoftRAM. Similarly, filling the block of code with assembly-language HALT instructions has no effect on SoftRAM's behavior, regardless of how much paging takes place. If control were ever to be transferred to this code, a HALT instruction would cause the machine to freeze.

The second thing that SoftRAM does to improve memory performance is permit a temporary paging file to grow to a size larger than Windows normally would allow. As described in the section on memory-enhancement techniques, this allows more memory to be allocated. However, this same effect can be accomplished by setting a parameter in system.ini. This has been SoftRAM's only line of defense against naysayers. Some benchmarks have shown that when SoftRAM is running, more applications can be loaded onto a system. If you see such a benchmark, note that in all cases a temporary swap file is in effect, and that the non-SoftRAM baseline system is crippled with an abnormally small paging file.

DoubleScan: A RAM Compression-Detection Utility

We have designed and implemented a program called "DoubleScan" that detects RAM compression. The program consists of a Windows program and a VxD (Virtual Device Driver). The Windows program allocates a buffer equal to the size of the physical memory that the program is running on. It then fills the memory with a user-configurable 8-byte string. Because Windows itself takes up a significant amount of physical memory, accessing the buffer will always cause paging. The VxD monitors all data that Windows sends to the paging file and counts the number of times the string appears in the data. Once the program has completely filled the buffer, the program pauses for a user-specifiable period, and then the VxD scans physical memory looking for the string. Syncronys has claimed that SoftRAM only compresses memory at idle time, so setting an idle period allows ample opportunity for it to do so.

In the absence of RAM compression, DoubleScan will find each instance of the string either in the data being sent to the disk, or in the memory it scans at completion. When RAM compression is occurring, DoubleScan will lose track of the strings that were sent to the paging file since compression will alter the string data.

When you execute DoubleScan, if the total number of pages DoubleScan finds with the signature equals the number of pages it allocated, then no compression was in effect. Table 1 shows the results of DoubleScan's execution under several different memory-enhancement tools.



              Compression    Time

Windows 3.1: 
Temporary Paging File
     
Native        no              31
SoftRAM       no              34
RAM Doubler   yes             14
MagnaRAM2     yes             15

Windows 3.1: 
Permanent Paging File

Native        no               25
SoftRAM       no               27
RAM Doubler   yes              14
MagnaRAM2     yes              12

Windows 95
   
Native        no               18
SoftRAM       no               18
MagnaRAM2     yes              12
Table 1: Sample DoubleScan results.

Because it might be claimed that RAM compression is only triggered on certain machines, the results listed were verified by running DoubleScan on a wide range of hardware platforms with varying memory sizes. It should be emphasized that DoubleScan is intended solely to detect compression and is not intended to be a performance benchmark. It is only because DoubleScan exercises RAM compressors with extremely unrealistic parameters that RAM compression appears to provide a benefit.

Statements from Syncronys

In fairness to Syncronys, we'll address the major challenges they have made to the analysis and experiments that have been presented. Synconys states:

"...the compression code is well hidden." Every component of SoftRAM has been thoroughly examined via disassembly and walked through with a system debugger.

"...the tools that have been used are 16-bit tools whereas SoftRAM is made up of 32-bit code." The tools that have been used in the study are all state-of-the-art. Both the debugger, NuMega Technologies' Soft-ICE/W, and the disassembler, V Communications' Sourcer, that were used are equally adept at 16- and 32-bit code.

Summary

The SoftRAM story is a fascinating study in how software can rocket to the top of the software retail charts. Fortunately, what we see in this case is generally only possible when a software product works behind the scenes. It is much more difficult to market a word-processing package that doesn't format text, for example, since this is something that will be immediately evident to the casual observer.

More information, including many of the newspaper and magazine articles that have covered SoftRAM, can be found at Andrew Schulman's SoftRAM Web site at: ftp://ftp.ora.com/pub/examples/windows/win95.update/softram.html.

Acknowledgments

The authors would like to thank Ingo Storm of c't Magazine, Richard Smith of Phar Lap Software, and Larry Seltzer of PC Magazine for their helpful discussions and insights.


Mark can be contacted at [email protected]; Bryce, at [email protected]; and Andrew, at [email protected].

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.