+1

Reply:

I too find that the people who post the most virulent and nasty posts are the least informed. I guess they figure that if they're nasty everyone will back off. They don't realize what idiots they are making of themselves. Even the best people in these forums will often say that "as far as they know..." or some such because we know how many variables there are in any version of Windows. Larry

+1

Reply:

Nipping back to Matt's posting. When I upgraded my RAM from 128M to 320M (W98SE) I was unsure whether I noticed any change at all. Obviously this must depend on your usage and what programs you run tho. Has anyone got any thoughts on the tailpiece to Matt's posting? Having limited the cache to 512M in system.ini do you still get the full value of the other 512M (Matt's example)? Derek.W

+1

Reply:

Here's a link SkipCox posted awhile back: http://jerseyd.com/ninetyeighttweaks.htm that shows step by step one way to accomodate 1 gig of ram. The page loads really slow.

+1

Reply:

ok, it will support up to 512MB.... but....WHY would you need 512MB for Windows 98? And plus...Windows 98 cant take FULL advantage of a 1.7GHz processor. Lets see you use 50% Processor usuage on that.... Back to my point, Windows 98 cant even take FULL advantage of your 1024MB. Hell, It cant even take full advantage of 256MB unless it runs for an extened period of time, but who would do that? I couldnt leave my Wi ndows 98 machine on for more than a week without it turning into s---, so I pulled some wires and got myself a copy of 2000 and it can run for over 2 weeks and still feal like a fresh boot.

+1

Reply:

Whew, your irrefutable logic is almost. . .almost. . . hypnotic. Even when you're wrong, you're right. My eyes have been opened. They may as well shut this forum down. 98 is nothing more than an anachronism, nothing more than an aged usurper to the Throne of Large Ram that, as IBMWarpster has eloquently shown, is all that matters. Well, it's time I packed up and went home. I guess I'll spend my remaining days watching Buffy reruns.

+1

Reply:

;>) IBMWarpster, This pasted in article is a couple of years old, but it illustrates the point; One oft-heard myth is that "Windows 95 can only handle 64 mb of RAM" or some variant on that theme. The truth is that Windows 95 and 98 are both designed to address 2 gb of RAM and there are as yet no motherboards which can hold this quantity although with 768 mb boards now widely available the 2 gb models can't be too far behind. This myth originated with the Pentium systems that used certain versions of the Intel chipsets (VX and TX I believe) which were designed so that only the first 64 mb of RAM would be supported by the L2 cache on the motherboard and RAM beyond 64 megabytes would therefore operate without the benefit of the L2 cache. On these motherboards the L2 cache was often described as "pipelined burst cache" and there was either 256K or more often 512K of this cache available. The report of memory beyond 64 mb not using the cache somehow got transformed into "more than 64 mb of memory won't work" and this misinformation persists. These particular Intel chipsets have long since gone out of production. I believe they were discontinued when the switch was made to the MMX version of the Pentium. Even if you have one of these older systems (I do) there is no need to feel that you would not benefit by having more than 64 mb of RAM installed. First of all, the overall impact of the L2 cache on system performance is about 10%. This has been measured by doing a series of timed application tests on a PC where all of the memory was being handled by the L2 cache. Then the system was reconfigured so that the L2 cache was totally shut down and the identical series of timed application tests was repeated. The end result was that shutting off the L2 cache completely increased the time required for the test series by 10%. So if you add additional RAM beyond 64 mb to your older Pentium system and as a result some part of your processing is done in uncached RAM rather than in cached RAM the maximum performance penalty you can expect is 10% with respect to that portion of the program load that is so affected. On the other hand, if the added RAM has the effect of reducing the use of the virtual memory swap file because more of the total system load can now be retained in physical RAM then the performance will be improved many many times. Raw access times for RAM are 1000 times faster than a hard disk, and data transfer rates are at least 25 times as fast. So the gain is very substantial indeed. The actual RAM limit for Windows 95. 98 and Me is 2 gb of physical RAM, as described in the Microsoft Knowledge Base article Q181594 http://support.microsoft.com/support/kb/articles/q181/5/94.asp However there are some vcache limitations that should be put into place with larger amounts of RAM by adding a MaxFileCache value to the [vcache] section of system.ini. The value entered should be approximately 70% of the total installed RAM in kilobytes, with an absolute maximum of 512000. Thus for a system with 384 mb of RAM the entry would read MaxFileCache=275000 and for systems with 700 mb or more it would be MaxFileCache=512000 The 70% limit is intended to prevent problems with vcache "runaway" that can otherwise occur when working with huge data files, meaning files that are equal to or greater than the total installed RAM, or when working with folders that contain vast numbers (tens of thousands) of data files. The 512000 absolute limit is an additional protection against "out of memory" errors that can otherwise occur if the vcache builds up to a very large value resulting in a lack of space in the 1 gb system components portion of the 4 gb virtual address space used by Windows.

+1

Reply:

More on the issue; http://aumha.org/a/memmgmt.htm Windows 98 & WinME Memory Management Updated March 6, 2001 Hold mouse here for list of most recent changes. Receive notice whenever this page is updated. Memory management in Windows 98 and Windows Millennium Edition (WinME) is dramatically improved over what existed in Windows 95. It is so much improved that, for nearly everyone, nearly all the time, the best recommendations on how best to optimize memory usage in Win98 is: Let Windows handle it. The main purpose of this article is to explain a controversial experiment currently being recommended in some quarters regarding Win98 memory management. Before discussing it directly, a little bit of background explanation seems advisable, which may be worthwhile for its own sake. IMPROVEMENTS IN WIN98/ME VCACHE Foremost among the improvements in Win98/ME memory management are the changes in VCache. Simply put, the VCache is used (among other functions) to store previously used code and data that Windows thinks might be needed again. If the code or data is just flushed from memory, but is then needed again, it has to be read anew from the hard drive when it is again needed. Reading from the hard drive is much slower than finding the code or data already in RAM. Some code is used quite often. If it has to be read from the hard drive over and over again, this would slow down performance considerably. The VCache concept is that, as long as there is unused RAM sitting about, we should just cache information in it that we might need again. (There is smart code that makes decisions about what to keep, how long to keep it, etc.; this has all been taken into consideration and is not particularly important to the present discussion.) Then, since this is only a “just in case” cache, if the RAM is needed for something else, part of the VCache contents are flushed and the RAM is made available. One improvement in VCache management in Win98/ME over Win95 is that Win95 had a bug that kept VCache from releasing RAM when it was needed. VCache would just keep growing sometimes, and the amount of available RAM would diminish accordingly, forcing more swap file activity (using the hard drive as a substitute for RAM). This is the famous “memory leak” of Win95. The user’s solution in Win95 was to put MinFileCache and MaxFileCache lines in the [vcache] section of the SYSTEM.INI file to control the size of VCache. This was sometimes a great help (especially on the 12 MB, 16MB, and 32MB systems which were the vogue in Win95’s heyday). But, in Win98, this problem was fixed (with further improvements in Windows 98 Second Edition, that carried over into WinME), and these [vcache] lines are not needed. Not only are they not needed, they actually get in the way in Win98/ME. In Win95 they improved performance, but in Win98/ME they decrease performance, because of a second improvement that was made in memory management for Win98 — to be discussed in a moment. But first, THREE EXCEPTIONS TO THE FOREGOING: EXCEPTION No. 1: For systems with more than 128 MB of RAM, setting a VCache maximum of about 70% of your total RAM is recommended as prophylaxis against run-away VCache growth in rare, specialized situations. (A tip of the hat to MS-MVPs Ron Martell, Ovidiu Popa, and Alex Nichol for months of experimentation and documentation of these details and recommendations.) EXCEPTION No. 2: VCache increasing above 512 MB can create serious memory handling problems. If you have more than 512 MB of RAM, a VCache maximum of 524,288 KB (or a little less) is recommended. This is obtained by adding a MaxFileCache=x entry in the [vcache] section of SYSTEM.INI, where x is the maximum value you wish to set. VCache is limited internally to a maximum cache size of 800 MB. The problem is that, on computers with large amounts of RAM, the maximum VCache size can be large enough that it consumes all of the available addresses in the system arena, leaving no virtual memory addresses available for other functions such as opening an MS-DOS prompt. This problem may occur more easily if you have an AGP video adapter: The AGP aperture is also mapped to addresses in the system arena, and if VCache is using its entire 800 MB allowance and an AGP video adapter has a 128 MB aperture mapped, there will be very little address space remaining for other system code and data that must occupy the available range of virtual addresses. EXCEPTION No. 3: For systems with more than 1 GB of RAM, the defaults in Windows 98 or ME can cause continuous rebooting of the computer, or to hangs or serial reboots during the Windows upgrade process. To resolve this problem, add a MaxPhysPage=40000 entry in the [386enh] section of SYSTEM.INI. This effectively limits the amount of RAM Windows can access to 1 GB. (Microsoft limits this recommendation to systems having more than 1.5 GB of RAM, but the solution is to roll it back to 1 GB. See MSKB Q304943.) Microsoft has now flatly stated that, “Windows Me and Windows 98 are not designed to handle more than 1 GB or RAM. More than 1 GB can lead to potential system instability.” The second improvement is that Windows can now execute code or access data directly from VCache. In Win95, this was not possible. If code was stored in VCache, it had to be passed to another part of RAM before it could be executed. This was still much faster than reading it again from the hard drive, but, nonetheless, took a small amount of time. In Win98/ME, it does not have to be moved to another part of RAM — it can be run directly from VCache itself. This saves a bit of time. In Win95, anything stored in VCache was disposable (but the “memory leak” bug prevented the trash from being taken out when necessary). In Win98/ME, code in VCache may not be disposable — it could be “live code,” part of a program you are using at the time. This explains why VCache sometimes seems not to give up memory that is needed for other functions. If code or data were stored in VCache only for caching purposes, then it should be emptied out before the swap file is used; but in Win98/ME, VCache often will stay quite large, forcing the swap file to be used more. Is this another memory leak? No, it isn’t. It would be a memory leak if the contents of VCache were only stored, inactive code or data. But if the contents are code or data currently being used (as it commonly will be in Win98/ME), we have quite another story! WHY IS THE SWAP FILE SO LARGE? For most people, in most situations, the best advice regarding the Win98 or WinME swap file is: Let Windows handle it. There are dozens of recommendations on ways to optimize it just a bit (some of which I use, and perpetuate, myself), but these are so system-dependent that it would take a huge article to explain all the ifs, ands, and buts of one approach over another in a particular situation. These discussions occur quite regularly online, on peer-support and general discussion newsgroups, so it is not hard to find opinions. I will indulge myself by giving one, which I regard as the least controversial and most helpful: The single best swap file arrangement is to have two physical hard drives, and to place the swap file — and nothing else! — on the first partition of the second physical drive. Be sure the partition is generously sized. Nonetheless, and to simplify the matter for the present, there is rarely any need for someone to worry about this in order to have a happily purring Win98/ME system. The general rule prevails: Let Windows handle it. A common confusion and concern is that, even with a great amount of RAM on the computer, Windows creates a swap file, and the swap file sometimes grows quite large. To respond to the first point: Windows will always create a swap file — that’s just the way it works. Also, some applications require swap file use even if Windows might not use it otherwise. Just expect this to be the case. Of more concern is that the swap file may seem to be much larger than is really needed. For example, my swap file at this moment is not being used at all (0 swap file usage, as measured by System Monitor), but the swap file’s allocated size (measured by Norton System Doctor) is 111 MB! Earlier today, the actual usage was about 10 MB, and the allocated size was 137 MB. Why in the world would this be? It is because Win98/ME “thinks ahead” more than Win95 did. One way it does this — since the resizing of the swap file is one of the biggest slowdowns to system performance on Win95 — is to more intelligently allocate space, in advance, for anticipated swap file needs. How does Windows know how much swap file space you might need in the near future? Each program specifies how much memory should be set aside (allocated) for its use. Generally, programmers request more memory than they need. (If done skillfully, this is a good thing: When running a program, one would rather have a bit too much memory available, rather than a bit too little, right?) This resembles reserving a table at a restaurant, even if you don’t plan to show up to eat, just in case you get hungry later. An OS has to allocate this requested memory for possible use by the program, even if it may never be used. Windows is smart enough to use the swap file for these “unused restaurant table reservations,” rather than use physical RAM! Think about it: This frees all of physical RAM for actual current memory needs — active program code, actively used data, etc. — and diverts the “wasted space” allocations away from physical RAM. If you have enough RAM, the swap file is never written to — it just takes reservations! The Swap File Usage monitor in Norton System Doctor measures the allocated size, whereas the equivalent gauge in Windows’ System Monitor measures the actual swap file usage. In the above example, with the many programs I presently have loaded, Windows thinks that I just might need over 100 MB of swap file space. It has prepared for that possibility ahead of time. This concept is central to the discussion below concerning one current recommendation of a way to handle Win98/ME memory management. The method below sounds, on first exposure, like a bad idea — but it may, in fact, have some worthwhile troubleshooting applications, and (if initial testing is any indication) may be worthy recommendation for Win98/ME systems with larger amounts of RAM installed. Whether good idea or bad, the technique deserves an airing and discussion. THE ADVANTAGES OF MORE RAM People often complain that they have added a lot of RAM to their computer, but very little of it is free. If Windows has anything at all it can do with the RAM, then free RAM is wasted RAM. Windows will try to make use of all of the RAM it can, for one good purpose or another. This benefits the user. Having unused RAM rarely benefits the user. In fact, the advantages of more RAM on a computer boil down to two: 1. Reducing swap file use. 2. Enabling a larger VCache. A large VCache is not a bad thing. Generally, it is a good thing (presuming Windows has a use for it at the moment). Bottom line: Let Windows handle it. NOTE: In Win95/98, if you have more than 1 GB of RAM, Windows may not start. A solution for this problem is given in the Microsoft Knowledge Base article “Error Message: Insufficient Memory to Initialize Windows.” The gist of Microsoft’s work-around is to artificially limit the amount of RAM to 768 MB. This may, however, be too stringent a restriction — a value only a little below 1 GB may solve the problem with less constraint on your RAM. A little experimentation will resolve this for you. THE “CONSERVATIVE SWAP FILE USAGE” TWEAK A WIn98/ME recommendation floating around various magazines and newsgroups is to add the following line to the [386Enh] section of the SYSTEM.INI file: ConservativeSwapfileUsage=1 Those who have used it, and reported favorably on it, say that it keeps their swap file usage lower, does not impede performance in any situation they have noticed, and seems to improve it in other situations. I have seen this reported on systems with 128 MB to 256 MB of RAM. I have seen it on my own 128 MB system. Is there anything to this? What does it do? Sometimes appearances can be deceiving. Sometimes not. Based on benchmark testing by MS-MVPs Mike Burgess, Alex Nichol, and other MS-MVP colleagues, I have concluded that this tweak can be of real value in many Win98/ME systems with 128 MB of RAM or more (and on some 64 MB systems). If your machine has sufficient RAM that, for your particular use of your computer, there is relatively little swap file usage, then this tweak will probably improve system performance by reducing the overhead in swap file maintenance activities that you do not really need. [NOTE: In contrast to behavior in Win98, testing of this by Mike Burgess in Windows Millennium Edition showed no significant performance difference with or without it. However, because it does affect swap file run-away growth on some computers — such as mine! — I am presently recommending this on Windows ME.] The default value of ConservativeSwapfileUsage was 1 in Win95, and 0 in Win98 and WinME. Therefore, this recommended tweak reverts a portion of the Win98/ME improved memory management system back to the way Win95 did things. (That’s what sounded like such a bad idea at first, because Win98 or ME is generally far superior to Win95 with regard to memory management.) A valid question, though, is whether it is a good (that is, useful) idea for systems that have grown past the RAM size originally contemplated as typical when Win98 was created. For many computers, the answer seems to be: Yes, it is. According to MS Knowledge Base article Q223294, Windows 98 added a new feature, PageFile_Call_Async_Manager, that allows the Memory Manager to asynchronously write out page file (swap file) buffers during periods of time when VFAT file system activity is not busy. This feature can affect the behavior of VxDs [virtual drivers] that monitor and/or otherwise intercept PageFile VxD functions. (See the article itself for more technical background on the rather clever way this function operates.) This feature is part of improvements made initially in Windows 98 that lend the appearance of faster performance to a Win98/ME computer because many of the small time-consuming activities are deferred to moments when you are not actually asking the computer to do anything. The tweak described above disables this feature. As MS-MVP Jeff Richards summarized it, “It’s more conservative in scheduling non-critical swap-file activity.” Microsoft advises that this change may be “at some cost in overall system performance.” Furthermore, in theory it would seem that this would make the computer seem slower. But only experimentation on a given system (and by a particular user on that system) can determine what the subjective performance difference (pro or con) would be. Based on experience to date, I would say it is probable that this tweak will have a positive effect on systems with an unusually large amount of RAM, and very little swap file activity. It is unlikely that it would have a positive effect on other systems, and might have a negative impact on their performance. Since the tweak is so easy to undo — just remove, or comment out the line added to SYSTEM.INI — “power users” will likely want to experiment with this and give more feedback to the general community. A NOTE FOR GAMERS: A dozen or so game boards discovered this page in December, 2001 and, according to the quarter million hits his page received in the next two days, I’m advised that this tweak makes Shadows of Luclin rock! Try it on your other games, too, if you’ve been having lagtime problems.

+1

Reply:

Thank you Dan. Great information.

+1

Reply:

hey folks, from my knowledge i read last time that the ratio of ram and the processor is to be only 1 : 4 Ram : Processor so just calculate it and find out how much ram ur pc needs for it to run. Enjoy, BONZI

+1

Reply:

You're welcome dave01. As I stated though, these are old articles which I "grew up with" for ram/vcache management. The metrics have changed in the last two to four years, but I posted them in the efforts to illustrate that 2GB of memory can be utilized in the Win9X realm. The rules of thumb are different now, but with experimentation based upon what you run on your system, excellent results/performance can be achieved. I've done it. (I know WhitPhil is watching.) ;>) Windows provides many tools beyond what the general user sees. Windows is used for anything from business applications to scientific/laboratory analyzation applications. You have to tailor the system to do what you want it to do. Once you set up the base O/S dependant upon your requirements, and add the programs required for your endeavours, it's a good system if maintained. It's not just a homeowners gate to the internet.

+1

Reply:

#11) DAVE - stop - you're killin' me! (ROTF) I may have to get into an argument just so I can work in some of those lines. (& a BtVS fan? Who knew?) Hey Dan Penny - nice bit of research. Better to remain silent and be thought a fool than to speak out and remove all doubt.

+1

Reply:

Sorry to bumb this up, but iv only just come back on to check for replys. And i have to say, i wasn't expecting such an amazing response. Thank you very much for all the info, i can now do some .ini fiddling and hopefully get my RAM working to maximum efficiency. I would like to add that as soon as i went from 512 to over a gig, the problems were obvious. And as soon as i changed the.ini the lack of problems was obvious. As for what i would need so much RAM for... One word - Planetside. Never seen a game that eats up so much RAM, it gobbles anything you throw at it! Thanks again.

+1

Reply:

I was reading your postings on RAM & SWAP issue - it is realy instructing. Do you happen to know someting about the use of RAM/swap file/"scratch disk" usage by graphic software such as Adobe Photoshop / Corel Draw and reccomend some hints/guidelines for setting them up on W95/98/2k systems? Thanks very much. PS - I very much enjoyed the way you handled "things" like IBMWarpster, your answer series is a real lecture! The world would be a better place with more like you!