It all started when a friend of mine sent me a link to the latest "How to Speed up Your RAM" tweaking article at Tom's Hardware Guide (THG). To be sure, I'm a hardware/software geek, but I haven't kept up much on memory tweaks and such over the last few years. Back in "the day", I used to be an expert on extended versus expanded memory, UMBs versus the HMA, and all that crap. The simple truth, however, is that I've been too busy working toward a degree for the last few years to keep up with all the latest and greatest developments in memory technology.
So I figured this was probably a good opportunity to fuss around with my RAM, to see what it could do. I thought that I would probably be able to use most, if not all, of the tweaks in the THG article. When last I bought memory, I purchased two 512 MB sticks of Mushkin 333 MHz. CAS2 DDR RAM with cooling shields. I paid extra for the CAS2 rating and the cooling shields, figuring that it wasn't worth scrimping when it comes to memory. Mushkin is a good name too, and that alone made it more expensive than the generic stuff. Read on to learn of my discoveries.
As I understand it, there was a time when coal miners depended for their very lives on canaries. Apparently, canaries are more sensitive to the accumulation of carbon monoxide than people and, as such, they provide a kind of macabre early warning system. If the birds start dropping dead in their cages beneath the Earth's surface, then the miners know that it's time to get the hell outta Dodge before they follow suit. In the modern era, I'm sure miners enjoy better options.
When it comes to computers, I find that 3D Mark 2003 (3DM03) is a sort of "stability canary". If there is even a hint of something wrong with my system, 3DM03 will fail in one way or another during its stock benchmark run. Sometimes it catches its own failure and gives me messages to the effect that this or that call failed. At other times it unceremoniously crashes back to the desktop with nary a peep. On rare occasions it even reboots Windows XP Professional entirely, which is never much fun. Suffice it to say that I use 3DM03 as a kind of stability meter; i.e., when it runs fine I figure my system is stable, and when it fails I figure something must be wrong somewhere.
Unfortunately, 3DM03 has been a bit twitchy since the latest ATI Catalyst video driver releases. It only crashed every once in a while with the v3.4 suite, but it's crashed a lot more since I updated to the v3.5 drivers. I've been somewhat concerned about this, mind you, but it's not like I've had a lot of time to track it down. Besides, even though 3DM03 has been crashing a lot on me, I've not had any issues with any of the games or other applications that I use. Like I said, 3DM03 is a sort of stability canary for my system. The fact that it was dropping dead made me worried that games or other apps might soon follow, but unlike the miners I wasn't sure what the problem might be.
Over time, I've settled on three benchmarks for evaluating my system as a whole: (1) 3DMark 2003, (2) Quake III Arena (Q3A) demo, and (3) Unreal Tournament 2003 (UT2k3). These three give me a good synthetic benchmark as well as a good benchmark for both OpenGL and Direct3D performance. I know some greatly distrust synthetic benchmarks, but I find them very useful for detecting small differences in system configuration, which makes them a useful tool for benchmarking memory tweaks.
As indicated already, I always use the standard benchmark in 3DM03. For the record, I'm running the Q3A and UT2k3 benchmarks at 1280 x 1024 x 32 bpp with all graphical settings cranked up to the max. The Q3A demo I'm using is DEMO001, which is included with the game demo. For UT2k3 I'm using the flyby benchmark for Inferno. I don't do any benchmarknig with any anti-aliasing or anisotropic filtering enabled, for I figure those tweaks have to be evaluated on a per-game basis.
The computer system itself is out of date in some respects, but it's still relatively beefy. It includes an Athlon CPU, a lot of memory, and pretty good peripherals. I don't benchmark without a sound card, network, etc.—as many reviewers misleadingly do—because it just doesn't reflect real-world performance. Simply having those components installed affects performance, as I've learned previously. For sake of reference, a more complete inventory of my system includes the following.
In every case I'm using all the latest patches and drivers for all my hardware and software. I've got the latest 4-in-1 pack from VIA, the latest ATI video drivers, the latest drivers for my Audigy 2, and so forth. It also bears mention that I've been running my front-side bus (FSB) at 138 MHz. with a multiplier of 15, and I've been overclocking my video card to 351/657 MHz. (GPU/Memory). All things considered, it was a pretty nice system before I started tweaking it.
When the THG article came along, however, I decided to spend a few minutes here and there fussing about with my system BIOS, and more specifically all the advanced options. My motherboard is a Gigabyte GA-7VAXP, and if you hit Ctrl+F1 on the main BIOS screen it will give you access to another page of advanced settings. These include manual control over memory timing parameters, a Fast Command setting—I have no idea whatsoever what it does—and some tweaks for the AGP and PCI buses as well.
What I found was rather surprising. I could change only one of the settings mentioned in the THG article without my canary assuming room temperature in a big hurry. That is, if I changed anything other than the DRAM Burst Length setting, then I could count on 3DM03 dying in one way or another. That's really a pity too, because altering some of the other settings didn't seem to cause problems with any games or other applications and gave up to a 10% boost in certain benchmarks.
What was even more surprising to me was that I couldn't configure my CAS2 memory to run at CAS2! I paid good money for fast memory with that rating, and I was quite disappointed to find that setting it to run at CAS2 resulted in an immediate lockup during startup. No matter what I tried with the other settings, I could not run the memory any faster than CAS2.5. Perhaps that makes sense to somebody else, but when I've paid good money for CAS2 memory I darned well expect it to run at CAS2. Silly me, eh? If nothing else, this doesn't give me much incentive to spend the money for good memory in the future.
It was also a bit disconcerting to find that some of the settings gave quite unexpected results. Changing the Fast Command setting to "Fast" improved performance noticeably, for example, but cranking it all the way up to "Ultra" actually slowed the machine down. Similarly, decreasing DRAM tWTR actually slowed down the machine noticeably, despite all of the reading indicating that it should provide some kind of boost. It's almost as if the various BIOS settings don't really mean what they're supposed to mean. Suffice it to say that my tweaking session was ultimately pretty confusing from start to finish. The following chart summarizes the contrast between the BIOS performance defaults, and what is actually fastest for my system.
Setting |
Default |
Tweaked |
| Fast Command | Normal | Fast |
| DRAM Timing | Auto | Auto |
| DRAM CAS Latency | 2.5 | 2.5 |
| Bank Interleave | 4 Bank | 4 Bank |
| Precharge to Active (Trp) | 3T | 3T |
| Tras Non-DDR400/DDR400 | 7T/10T | 7T/10T |
| Active to CMD (Trcd) | 3T | 3T |
| DRAM Burst Length | 4 | 8 |
| DRAM Queue Depth | 4 | 4 |
| DRAM Command Rate | 2T | 2T |
| Write Recovery Time | 3T | 3T |
| DRAM tWTR | 3T | 3T |
| AGP Aperture Size | 128 MB | 128 MB |
| Current AGP Transfer Rate | 8X | 8X |
| AGP Fast Write Enabled | Enabled | Disabled |
| AGP 3.0 Calibration Cycle | Enabled | Enabled |
| PCI Delay Transaction | Enabled | Enabled |
As one can see, the parameters that changed are Fast Command, DRAM Burst Length, and AGP Fast Write Enabled. Fast Command and DRAM Burst Length both give noticeable performance boosts across all benchmarks. Disabling Fast Write, which seems to be poorly named, results in increased performance in 3DM03 but actually decreases performance in other benchmarks and especially in other games. Amazingly enough, enabling Fast Write more than halves my system's performance when playing Raven Shield, though why a technology designed to speed things up would do this is beyond me. Suffice it to say, however, that the results of all three changes are reliable and repeatable.
Prior to benchmarking, my scores for the three benchmarks were 4888 3D Marks, 187.4 FPS in Q3A, and 100.3 in UT2k3. Loading the BIOS performance defaults and setting the above tweaks gives results of 5063 3D Marks, 201.8 FPS in Q3A, and 101.9 in UT2k3. My tweaking thus results in performance boosts of 3.6%, 7.7%, and 1.6% respectively. That's not going to make anyone mistake my machine for a bleeding edge system, but it's enough to make the computer run noticeably smoother in several games and applications. The way I see it, any boost that doesn't cost me money or stability is an especially good boost.
Most surprising along the way was the degree to which small memory tweaks rendered my system unstable, though only in very specific circumstances. The THG article suggested, for example, that I should set my command rate as low as possible, which on my system is to set DRAM Command Rate to 1T. Doing this gives a very noticeable performance boost across the board; in fact, the system is perceptably snappier at startup. I was quite pleased when I saw the results during the following reboot.
I wasn't so pleased, however, when 3DM03 dumped back to the desktop whenever I tried to benchmark the system. The program would always terminate without so much as an error message at some point in its default benchmark sequence, though typically near its end. Worse, after 3DM03 failed, my system would reboot itself completely if I tried to run certain games. This was truly a pity, for I saw no stability issues with most of my games. Changing the command rate gave a clear boost in the Q3A benchmark, in Raven Shield, Battlefield 1942, etc. Like I said earlier, though, I treat 3DM03 as my "stability canary", and when the canary is dropping dead it's assumed that something is definitely wrong beneath the hood.
The final serious problem worth noting was a compatibility issue with, of all games, Diablo II (D2). I log on to Battle.net every couple of months to play my characters in order to keep them from being deleted. It's probably a silly thing for me to do, but I have so much time and effort invested in a couple of them (e.g., a L60 ice/lightning sorceress named Kelikali) that I just can't bear to let them vanish into the ether. When I tried to play D2, however, I was in for a rude shock: my system hung hard a few seconds after the game launched.
The pattern was the same every time. I would launch the game, click past the two opening movies—here's a side note to game developers: always give the user a command-line switch or something to skip those damnable things!—and get to the opening menu screen. The first musical phrase that plays would then loop a few times while the system was unresponsive, after which it would either sit there making the most dreadful squealing and crackling noises or reboot itself altogether. Maybe it's just me, but I don't think D2 is supposed to work like that.
To shorten an already long story, I had to stop running D2 using Direct3D. I used the included video test utility to set it to DirectDraw instead, which eschews all of my video card's hardware acceleration features for 3D graphics. As I understand it, that means that some of the spell effects and such in the game aren't as pretty as they otherwise would be, but I haven't noticed any difference. Frankly, I wish I'd thought of that sooner, as I spent a great deal of time trying to figure out why D2 was dying and which tweaks were responsible. I never did get any good answers, though I did discover that I could avoid the crash by loading the fail-safe BIOS defaults. Why such instability would manifest itself only with D2 is beyond me.
The first conclusion to draw from this whole experience is this: it really does make sense to test your BIOS settings one at a time for sake of performance. Quite simply, the names the vendors apply to the various settings (e.g., "Normal", "Fast", and "Ultra" for Fast Command) don't necessarily provide the results one expects given their names. The requisite testing is insanely tedious, of course, because it requires a complete reboot of the system after each test, and, as such, each testing run takes quite a bit of time. I took the data while I was working on another computer, however, so it wasn't such a big deal for me. Folks who don't have a second computer handy might not want to spend the time and effort, but I think it's worth it.
Second, loading different sets of BIOS settings clearly does more than merely changing the visible options. My system has two different sets of default values that may be loaded, fail-safe and performance. I don't know why this is the case, but I get entirely repeatable and reliable differences between (1) loading the performance defaults, and (2) loading the fail-safe defaults and setting all of the available values to match the performance defaults. This difference was also highlighted by the fact that loading the performance defaults and changing all the settings to the fail-safe values would still cause D2 to crash, whereas loading the fail-safe defaults and changing all the settings to the performance values would not. In effect, it is obvious that the system has some very important settings that are not available to the user at all. Perhaps this is obvious to some, but it wasn't to me.
Third, and paradoxically enough, my system's stability has been improved through this process. I can't explain why any of the changes I made should make the system more stable, but they have. It's crashed on me only once in the last couple of weeks since I finished my tweaking, and that's an improvement. It used to crash once every few days, typically when I was in the middle of playing a game. The only crash I've had since tweaking my settings was while playing Warcraft 3: The Frozen Throne, and that might have been caused by the heat in retrospect. I do overclock my video card, after all, and it was quite hot in my office that day (over 100° F).
All things considered, I'm glad I took the time to investigate my memory timings. I didn't come up with the results I expected in several respects, but I do think the results justify the time and effort expended. If nothing else, I now have a clearer procedure for wringing all the bugs and stability issues out of any new system I build. That alone is worth a lot to me.
07/18/2003