- Sep 21, 2008
- 4,568
- 10
- 23,160
Memory - Part IV - "Tweaking and tuning"
other content:
Part I - What memory is"
Part II - "What memory does"
Part III - "Evaluation and selection"
...the 'original debugger'...
Making it work!
Pretty much all modern computer systems have a 'central' clocking system, which allows them to coordinate their various subsystems which want to run at their own limits. This is referred to, in general, as a 'Bclk' (base clock). For 775 based systems, it's under "CPU Host Clock", and four times your host clock is your FSB (front system bus); Intel's 775 CPUs are rated at four FSBs: 800 (200 Bclk), 1066 (266 Bclk), 1333 (333 Bclk), and, at a grand a pop, 1600 (400 Bclk). For AMDs, it's also under "CPU Host Clock", and usually has a 'stock' setting of 200 MHz. For the Intel 1136/1566 platform (i3/i5/i7), it's actually called the 'Bclk', and has a 'stock' setting of 133MHz.
The various subsystems typically have their own multiplier, which, times the Bclk, sets their speeds. Here is a diagram of these 'subsystems' and their multipliers, for the i7:
There are a couple of "rules" to remember for the 'iCores' in reference to this diagram: first, the 'Uncore' multiplier must be at least twice the memory multiplier (and experience has shown that the processors 'like' odd uncore multipliers, so the best situation is uncore mult = [ 2 x memory mult ] + 1 ); second, the QPI/Vtt voltage must be within a half-volt of the Vdimm. The first is generally not an issue with i7's, as the uncore multipliers can be 'cranked' pretty well; however, it is an issue to be aware of with i5's - they have a 'locked' uncore (see below...), which, at 20x, also places a top limit on the memory multiplier, that you should be aware of when 'picking' memory for these - you can never get a memory multiplier higher than 10x, so any RAM speed above 1333 ('stock' 133 Bclk x 10 = 1333) will require raising the Bclk itself to accomplish... The second is also an issue with high-speed memory; most fast DDR3 is rated at 1.65V Vdimm, but the 'stock' setting for QPI/Vtt is typically 1.1V - that gives you a 'spread' of .55V: higher than the 'allowed' half-volt! Not really a problem though - so long as you are aware that you need to increase the Vtt when 'bumping up' the Vdimm. The i7 'spec maxes' for these (and people do run 'em higher - but, hey - it's your expensive puddle of molten silicon, do what you wish
!) are: Vttd & Vtta (same Vreg...) ≤ 1.35V; Vdimm ≤ 1.875!
The 'nature' of multipliers...
For AMD, and 775 processors, the multipliers 'look' like decimal numbers - but they are not! You are not able to just 'dial in' any speed you want - they are fixed, integer-based divider networks, in the circuitry. For example the AMD's '5.33' setting is actually an 8:3 integer divider, meant to give you a nice, even 1066 RAM speed with the 'stock' 200MHz base clock, and the 6.66 (fundamentalists [:lorbat:5], beware!) is 10:3, which results in 1333 RAM. (Note - the math 'divides out' to one-half the 'displayed' RAM speed, as DDR is 'double data rate' - it transfers data on both the rising and falling 'edge' of its clock, meaning the physical clock speed is one-half the DDR 'rate'...)
For 775 processors and northbridges, the following table may make it clearer, as it shows both the actual multiplier ratios, as well as the process of progressively 'walking up' the frequencies/ratios, to allow DDR2-1066 to accommodate various Bclks:
'Locked' multipliers and 'Locked' multipliers!
Much like The difference between "Supported Speed", and "Supported Speed"! topic in Part III - "Evaluation and selection", most mutipliers reffered to as 'locked' are not actually - they are a range of adjustable multipliers that are 'capped' or 'top limited'; these are usually the Core Multilpliers cited in stating the CPU's 'standard speed'. An i3-540 is rated at 3.06 GHz, as the stock Bclk (133) times its max core multiplier, 23, gives you 3.059. You can use any lower multilplier at will. On the other hand, there are actually locked multipliers. For the i5 processors, the 'uncore' multipliers are locked at 20x - can't raise 'em, can't lower 'em!
Timings, 'sub-timings', and "why is this crap a secret?"
As previously discussed in Part I, DRAM is arranged in multi-dimensional 'arrays', and the need to 'activate' or change any one of these 'dimensions' incurs a physical cost in time - the 'latencies'. The main latencies are usually shown as: CAS-tRCD-tRP-tRAS. i.e., 7-7-7-21... Many of these 'dimension changes' or selections are referred to as 'strobes': the act of 'pulling an address line high' - so, we have:
The BIG FOUR!
■CAS: column address strobe; time betwixt the memory controller telling the RAM to access a column, and the data from that column being available at the RAM's outputs...
■tRCD: RAS to CAS delay; time between a row activate command, and a read/write command to that row...
■tRP: row precharge; time necessary to terminate access to an open row , and open access to the next row...
■tRAS: row address strobe; time needed to access a particular row of data in RAM, between the data request and the precharge commands...
And, from some manufacturers, WE CAN'T EVEN GET THESE! I won't name names here (however, be afraid - be very afraid!), but a couple 'makers' only give CAS timings for their products, and THAT'S IT!! [:bilbat:3] If everyone 'voted with their dollars', this would be cured within two months! Either they'd go out of business (which they so richly deserve), or, we'd get decent documentation - manufacturers, take your pick! Follow my policy: click on that NE 'manufacturer's links' tab - follow that 'product page' link... If they don't post decent technical data - what can you possibly expect their support to resemble?? Some can't even manage to have the link 'point to' the product
! I'm sorry; if you 'can't be bothered' to provide access to necessary manuals and relevant documentation, then I 'can't be bothered' to order your product - end of story!! OK - rant over...
If you'd like to see some actual, detailed, specific tech docs, visit Micron: sample_doc | SPD_info | SPD_technote... ?
?
Anyway, in addition to the 'big four', there are numerous other 'physical delays', linked to other aspects of 'physical access' to the RAM circuits themselves; all of these are important, and any one set wrong can 'bolix up' your whole memory set-up! Rather than try to detail all of these, I'll just reference a couple good pages at TweakTown, and Tweakers for further explanation; the best (so far - in view of available documentation) place to find these little tidbits about your particular RAM is in the SPD the DIMMs contain, discussed next...
SPD, EPP, XMP, and "can't we all just get along?"
The SPD on each DIMM (serial presence detect - I know - didn't make any sense to me either, until I stumbled across this: "early 72-pin SIMMs included 5 pins which provided 5 bits of parallel presence detect (PPD) data; the 168-pin DIMM standard changed to a serial presence detect to encode much more information") contains all the data your BIOS needs to configure your particular memory for use by your system, and sometimes more... It is a seperate, 'self-contained' subsystem: has a couple configuration pins [SA0 & SA2, pins 239 & 240], its own supply voltage [VddSPD, pin 238], its own clock [SCL, pin 120], and a single data line, SDA on pin 119 of the DIMM. This table of data is very precisely defined by JEDEC, and the data definitions can be seen here, at SimmTester, unless you want to 'struggle through' the actual JEDEC DDR3 SPD doc, here... Be aware, though, that there are at least nine 'addenda' to the SPD docs - 'annexes' A through J [:bilbat:7]! A number of utilities will also give you 'views', of varying completeness:
In addition to the 'basic', required data for the JEDEC standard clock speeds for your RAM, the SPD is allowed (but not required) to contain additional data sets for faster, non-standard speeds. However, in one of their little 'pissing contests', AMD (actually, originally nVidia and Corsair) have one data set, called an EPP - enhanced performance profile, for their extension; and Intel has another, different one, called XMP - extreme memory profile, for theirs! I, frankly, just don't get it: these extensions could, in theory, 'coexist', as the EPP occupies bytes 99-127 of the SPD 'space', while the XMP uses bytes 176–255; you could have both on every high-speed DIMM - but, I suppose the bits would form little green and blue warring 'camps' inside the modules!
I am currently unsure whether the recent crop of AMD chipsets/CPUs support the EPP extension at all... When I find out, I will update here - gotta read the AMD start-up sample stuff in 'pseudo-code', which will take a while - looks to be somewhat longer than Psalms! [:fixitbil:1]
'Sidestepping' XMP's limitations:
I don't know if this is an issue for most MOBOs, but, at least on GIGABYTES', enabling XMP - disables pretty much every other clocking and voltage adjustment! ^%$#! I've tried to come up with a slick way of conquering this, using the BIOS' CMOS parameter 'storage slots', but - it just ain't happening! Boils down to the fact that enabling XMP changes all the parameters instantaneously, rather that awaiting the next boot, as does disabling it - no way to 'get in between' to save the XMP memory parameters, without it being enabled, crippling everything else!
So - the 'clumsy workaround' (actually, only takes about five or eight minutes to 'dial-in' [:isamuelson:8] ):
■Put one DIMM in the slot recommended for 'single sticks' in the manual - just to make sure it works...
■Do a "Load Optimized" from the BIOS' main page, to get an initial 'good setup'; <F10> to save, exit, and reboot...
■Do an <F11> "Save to BIOS", naming the 'slot' someting like 'BaseLine' - now you can 'get back' in case of [:lorbat:6] ...
■Enable XMP; again, <F10> to save, exit, and reboot...
■Run a pass or two of MemTest (see below...) to verify functioning XMP setup...
■Go through your BIOS, and write down all relevant settings, including:
----> ALL memory timings, NOT JUST CAS-tRCD-tRP-tRAS, ALL of 'em!
----> 'Profile Vddr'*
----> 'Profile QPI/Vtt'*
----> 'Bclk' (remember, if your RAM is faster than 1333 with an i5, XMP will 'bump' your Bclk!*
----> Memory multiplier*
----> Uncore multiplier* (if applicable - n/a for i5's...)
■Disable XMP, once again, <F10> to save, exit, and reboot...
Now, finally, you're ready for the 'dial-in'! You have a list, primarily, of the full memory parameter set for your RAM's rated speed. Let's say we're looking at some DDR3-1600... The memory controller doesn't care if that's: a 133Bclk x 12 memory multiplier, or a 160Bclk x 10 memory multiplier, or 200Bclk x 8 memory multiplier; 1600 is 1600, and your 'parameter set' should work for any of 'em! All of the parameters above marked with * can be 'fiddled with'... Now's the time to decide where you want to go with your setup, how much overclocking, how much voltage/heat you'll commit to; it's a good time to double check that your 'Profile QPI/Vtt is 'comfortably' within the half-volt limit compared to the Vddr, and if it's 'close', bump it up a bit; see if you can get that uncore multiplier to the next integer above two times the memory multiplier; don't forget that if you're raising the Bclk, you'll want to lower the QPI multiplier to stay within the 'realm of the possible'. Dial in all your settings in the BIOS, do an <F11> 'save to BIOS', calling the 'slot' something like "MyXMPTry1", so you can 'get back here', do the <F10> save, exit, and reboot - and - the moment of truth! See if she boots! Also, another good time to run a pass or two of MemTest, just for confirmation...
If she looks good, power down, put in the other DIMM (for 1156), or the other two dimms (for 1366), and try again - and, another Memtest pass, if you please! At this point, however, limit your testing to two (or three) DIMMs - to run more than a DIMM per channel will likely take some futher adjustment...
Two DIMMs per channel 'adjustments':
Electrical impulses do not 'travel' instantaneously from point to point on your board. Much like the memory's latencies, there are finite 'time losses' for a signal to get 'from A to B'! As obviously, all your DIMMs can't be exactly the same distance from your memory controller (be it northbridge or CPU), the signalling will be 'skewed' to some of your DIMMs. The board designers rely on 'meanders', sort of 'maze-like' runs of circuit board traces, to try to make these lines as equal as possible; but, the 'meandering', itself, causes induced capacitance and inductance, which also changes the signal timing - so there's only so much that can be done... Some memory controllers are capable of storing certain timing parameters on a 'per DIMM' basis to try to accomodate these differences, and these are usually set 'in auto' by the BIOS/controller's 'training routines' (another good reason to stay withing the 'supported' guidlines from The difference between "Supported Speed", and "Supported Speed"! in Part III - "Evaluation and selection"); you are likely better off to not 'fiddle with' these - without access to about three thousand dollars and up worth of logic analyzer, it takes skill and luck to improve on these settings through trial and error (mostly - error)! Because of these 'per DIMM' differences, however, it should be apparent that the timing parameters need to be somewhat 'relaxed', or slowed, to allow for these signals to 'catch up' with each other... For many setups, increasing tRFC by roughly 10-15%, and checking that your Command Rate (actually, 'commands-per-clock' - whether your controller can issue a command each clock cycle, or only alternating clocks...) is set to 2 ('2T' or '2N', depending on your system), will take care of these 'skews'.
Another thing that multiple DIMMs per channel do is to cause increased 'loading' of the DIMM supplies themselves, as well as all the signal lines. This is why having more than one DIMM per channel usually requires additional voltage: from a tenth to a tenth-and-a-half of additional vMCH for northbridge-based controllers, to from a few hundreths to a tenth of extra vDIMM for CPU-based controllers. For some reason, OCZs seem to be particularly 'voltage-hungry', and may want to be run toward the top of the cited ranges...
Tweaking, testing, and tuning - practical techniques:
blah blah blah
Memtest Techniques:
First 'jewel of wisdom': there is "MemTest", and there is "Memtest86+"; the former has occasionally been known to be 'buggy' - the latter is the one you want! Current version: Memtest86+ v4.10 Extract the downloaded .zip file, "memtest86+-4.10.iso.zip", which will give you an .iso file: "mt410.iso"; 'burn' the .iso to a CD-Rom... If you are running any of the various 'flavors' of seven, the 'burner' is 'native' - simply right-click on the .iso file, select 'Open With' > 'Windows Disk Image Burner', check 'Verify Disk After Burning', 'Burn', and you're good; or, use the 'burner that came with your DVD/CD drive, either Roxio or Nero, or, if your drive, like several of mine, came only with a nifty piece of re-useable bubble-wrap, there are some free CD/DVD burners here... However you do the burn, the next step is to boot to it: you will either want to change the BIOS' "first boot device", on the "Advanced BIOS Features" page to 'CDROM', or use the 'press any key to boot to CDROM' prompt that appears when you put a bootable CD into the drive at boot time (which, I believe, is a 'standard feature' of all GB BIOS - allows you to run the 'XpressRecovery' function from your included driver disk) - for which you may need to enable the "USB Keyboard Support" item on the "Integrated Peripherals"...
Changelogs (in case you've never seen an actual one![:bilbat:7]) and general info are available at memtest.org; there is also a support forum at CanardPC.com, but, it is for Memtest issues only (i.e., bug reports and feature requests) - not help with your particular hardware/memory issues!
Not many people are aware that Memtest86+ comes in 'create a bootable USB key' and 'create a bootable floppy' flavors!
To make the 'bootable flash drive' flavor: extract the downloaded file, "memtest86+-4.10.usb.installer.zip" to a location you can remember [:lectrocrew:7], which will result in a single file: "Memtest86+ 4.10 USB Installer.exe"; double-click on that file, and it will 'launch' the following sequence:
In the first 'frame', you will need to select your drive, and check the 'format' item. I will tell you the same thing I mention in the Bootable Flash Drive Tutorial: "You can't accidentally format your hard drive with this thing, but I don't want to hear any whining about having erased poor, dead, Aunt Bessie's pictures from your camera's SD stick, or having formatted your iPod or USB back-up drive by mistake, so check that the first item 'points' to your actual flash drive - do it now!" The remaining 'frames' are pretty 'idiot-proof'; all that remains is to enter your BIOS, set your first boot device to 'USB-HDD', and the "Legacy USB storage detect" (later BIOS say "USB Storage Function") on the "Integrated Peripherals" page to "Enabled", and you should be ready to rock!
To make the 'bootable floppy' flavor: extract the downloaded file, "memtest86+-4.10.floppy.zip", again, to a location you can remember [:lectrocrew:7], which will result in a 'floppy' folder/directory containing these files:
dd.exe
install.bat
install64.bat
memtestp.bin
rawrite.exe
README.txt
Double-click on 'install.bat' if you are running 32-bit windoze; 'install64.bat' if you are running 64-bit windoze - no biggie here, if you 'pick' the wrong one, it'll politely 'tell you', as in frame 1:
If you get it right, it'll sequence through frame 2 to frame 3; all that remains is, once again, to enter your BIOS, set your first boot device to 'Floppy' this time, save, and reboot!
If you aren't interested in the 'gory details', you can just scroll through this, down to the next purple entry - Memtest Useage: (it will work perfectly fine for you, without any participation from you, beyond getting it 'launchable') but - folks often ask about individual tests, or just generally "what the hell does it do?" - so, I thought, this was the spot!
Memtest's Testing Philosophy [:isamuelson:8]
There are many good approaches for testing memory. However, many tests simply 'throw some patterns' at memory without much thought or knowledge of memory architecture or how errors can best be detected. This works fine for hard memory failures but does little to find intermittent errors. BIOS based memory tests are useless for finding intermittent memory errors.
Memory chips consist of a large array of tightly packed memory cells (see Part I - What memory is") , one for each bit of data. The vast majority of the intermittent failures are a result of interaction between these memory cells. Often writing a memory cell can cause one of the adjacent cells to be written with the same data. An effective memory test attempts to test for this condition. Therefore, an ideal strategy for testing memory would be the following:
■1. write a cell with a zero
■2. write all of the adjacent cells with a one, one or more times
■3. check that the first cell still has a zero
It should be obvious that this strategy requires an exact knowledge of how the memory cells are laid out on the chip. In addition there is a never ending number of possible chip layouts for different chip types and manufacturers making this strategy impractical. However, there are testing algorithms that can approximate this ideal.
Test Algorithms²
Memtest86 uses two algorithms² that provide a reasonable approximation of the ideal test strategy above. The first of these strategies is called moving inversions. The moving inversion test works as follows:
■1. Fill memory with a pattern
■2. Starting at the lowest address:
■----->◦check that the pattern has not changed
■----->◦write the patterns' complement
■----->◦increment the address
■----->◦repeat
■3. Starting at the highest address:
■----->◦check that the pattern has not changed
■----->◦write the patterns' complement
■----->◦decrement the address
■----->◦repeat
This algorithm² is a good approximation of an ideal memory test but there are some limitations. Most high density chips today store data 4 to 16 bits wide. With chips that are more than one bit wide it is impossible to selectively read or write just one bit. This means that we cannot guarantee that all adjacent cells have been tested for interaction. In this case the best we can do is to use some patterns to insure that all adjacent cells have at least been written with all possible one and zero combinations.
note²: Algorithm is 'loosely used', here - technically, an algorithm is a precise step-by-step plan for a computational procedure that begins with an input value and yields an output value in a finite number of steps; commonly, it is abused to represent simply 'any well-defined computational procedure'... [/i]
Caching, buffering, and 'out of order execution' will interfere with the moving inversions algorithm and make less effective. It is possible to turn off cache but the memory buffering in new high performance chips can not be disabled. To address this limitation a new algorithm, Modulo-X was created. This algorithm is not affected by cache or buffering. The algorithm works as follows:
■1. For starting offsets of 0 - 20 do:
■----->◦write every 20th location with a pattern
■----->◦write all other locations with the patterns' complement
■----->◦repeat above one or more times
■----->◦check every 20th location for the pattern
This algorithm accomplishes nearly the same level of adjacency testing as moving inversions but is not affected by caching or buffering. Since separate write passes, and the read pass, are done for all of memory we can be assured that all of the buffers and cache have been flushed between passes.
Regarding 'interpreting' individual tests, MemTest has this to say about that:
Memtest86 executes a series of numbered test sections to check for errors. These test sections consist of a combination of test algorithm, data pattern and cache setting. The execution order for these tests is arranged so that errors will be detected as rapidly as possible. A description of each of the test sections follows:
■Test 0 [Address test, walking ones, no cache]
Tests all address bits in all memory banks by using a walking ones address pattern.
■Test 1 [Address test, own address]
Each address is written with its own address and then is checked for consistency. In theory previous tests should have caught any memory addressing problems. This test should catch any addressing errors that somehow were not previously detected.
■Test 2 [Moving inversions, ones & zeros]
This test uses the moving inversions algorithm with patterns of all ones and zeros. Cache is enabled even though it interferes to some degree with the test algorithm. With cache enabled this test does not take long and should quickly find all "hard" errors and some more subtle errors. This test is only a quick check.
■Test 3 [Moving inversions, 8 bit pattern]
This is the same as test one but uses a 8 bit wide pattern of "walking" ones and zeros. This test will better detect subtle errors in "wide" memory chips. A total of 20 data patterns are used.
■Test 4 [Moving inversions, random pattern]
This test uses the same algorithm as test 1 but the data pattern is a random number and its complement. This test is particularly effective in finding difficult to detect data sensitive errors. A total of 60 patterns are used. The random number sequence is different with each pass so multiple passes increase effectiveness.
■Test 5 [Block move, 64 moves]
This test stresses memory by using block move (movsl) instructions and is based on Robert Redelmeier's burnBX test. Memory is initialized with shifting patterns that are inverted every 8 bytes. Then 4mb blocks of memory are moved around using the movsl instruction. After the moves are completed the data patterns are checked. Because the data is checked only after the memory moves are completed it is not possible to know where the error occurred. The addresses reported are only for where the bad pattern was found. Since the moves are constrained to a 8mb segment of memory the failing address will always be less than 8mb away from the reported address. Errors from this test are not used to calculate BadRAM patterns.
■Test 6 [Moving inversions, 32 bit pattern]
This is a variation of the moving inversions algorithm that shifts the data pattern left one bit for each successive address. The starting bit position is shifted left for each pass. To use all possible data patterns 32 passes are required. This test is quite effective at detecting data sensitive errors but the execution time is long.
■Test 7 [Random number sequence]
This test writes a series of random numbers into memory. By resetting the seed for the random number the same sequence of number can be created for a reference. The initial pattern is checked and then complemented and checked again on the next pass. However, unlike the moving inversions test writing and checking can only be done in the forward direction.
■Test 8 [Modulo 20, ones & zeros]
Using the Modulo-X algorithm should uncover errors that are not detected by moving inversions due to cache and buffering interference with the the algorithm. As with test one only ones and zeros are used for data patterns.
■Test 9 [Bit fade test, 90 min, 2 patterns]
The bit fade test initializes all of memory with a pattern and then sleeps for 90 minutes. Then memory is examined to see if any memory bits have changed. All ones and all zero patterns are used. This test takes at least three hours to complete. The Bit Fade test is not included in the normal test sequence and must be run manually via the runtime configuration menu.
Memtest Useage:
Pre-assembly DIMM 'qualification':
The first thing I do, when I start a 'system assembly' project, is to lay the board out, on an insulated surface, near the case and power supply; install the power connectors, the vidcard, a case speaker, the minimum of front panel wires, the CPU and HSF, and one DIMM - and then 'power her up', just to verify 'the basics' are working. The very next step I undertake, is to do a "Load Optimized", hook up a DVD, set 'er up to boot from it, and run a copy of Memtest on just that DIMM, usually overnight... When I get up in the morning, I verify the test results were good - switch DIMMs (same slot), and 'let 'er rip' again; assuming two DIMMs, by late that afternoon, I have confirmed two 'healthy' memory modules! Then, and only then - time to proceed!
If you are planning to overclock, another useful step at this point is to 'qualify' your RAM for overclocking; as well as 'characterize' each DIMM. If you intend to use, or need to test the capability of the XMP on your DIMMs, this is the time to do it. If you're planning on using higher speeds, or lower latencies than your DIMMs are 'documented at', ditto!
The reason I recommend a "LoadOpt" before each test is to 'ferret out' the (slim) possibility of a defective SPD on a given module; each time you do the "LoadOpt" with a single DIMM, it forces the BIOS to 'read' the SPD, and set itself accordingly - with a bad SPD (incorrect or 'scrambled' data), the "LoadOpt" will fail to give a 'working' configuration - revealing the DIMM as bad. If, however, several DIMMs fail this test, you may have a bad memory controller - or, you may be damaging them through handling (you are wearing that 'anti-stat' bracelet, aren't you?)
Full memory setup verification:
Having done the 'pre-assembly qualification' gives you an advantage in the process of tuning/tweaking your memory - you know the DIMMs are good! Whether your memory setup procedure is simply doing a "Load Optimized" from the BIOS, enabling XMP, or the much more involved process of adjusting for two DIMMs per channel or 'hand' overclocking of your memory, when you are finished and happy with your setup, another couple of passes of Memtest is just the thing to ensure your board and CPU are 'happy with' your setup! If she doesn't pass - back to the drawing board - another round of 'tweaking' is in order...
'Hunting down' a bad DIMM:
Things fail! Memory is not immune. Electronics are prone to fail shortly after their first use - this is known as 'infant mortality'. Often, the first clue is the infamous BSOD; in addition, sudden resets during, or halts of, installations (both OS and program) can be an indicator of a memory failure. Some memory would also appear to 'age', causing a once-working setup to show errors that can be repaired by slightly raising the Vdimm, or increasing the timings... First thing you need to know when these symptoms rear their ugly heads is "do I have a bad DIMM?" Memtest will again tell you - what you need to do is simply return to the same procedure listed above, in Pre-assembly DIMM 'qualification': one DIMM at a time, "Load Optimized" before each, to verify each one's integrity.
MemSet/CPU-Tweaker Technique:
MemSet and CPU-Tweaker are a pair of invaluable programs from the French site 'Tweakers'; (once again, polish up that high-school French, s'il vous plaît!) they are 'two sides of the same coin'... Both are intended to allow you to 'fiddle' your memory timings while running, for testing purposes; MemSet (current version: MemSet 4.1) is made to work with older 775 systems whose memory controller in on the system's northbridge; CPU-Tweaker (current version: CPU-Tweaker 1.5) works with both AMDs, and Intels with memory controllers integrated on the processor die; don't worry too much about getting the right one - if you manage to try to use the wrong one, it'll politely suggest that you run the other! [:bilbat:5]
Now, like I said, these programs are made to let you 'diddle around' with your memory timings, and sub-timings, 'on-the-fly' - and you can do that (I'll discuss that particular use later...) - BUT - I've found a procedure that has 'discovered' the problems in a number of posters' RAM setups, in a pretty straghtforward and 'obvious' way - and here's the secret: both of these programs give you an excellent view of your 'currently set' timings, and also are able to display more of the SPD data on your DIMMs than any (but one³) other program I know of! It's pretty simple to open up either one, click on its 'SPD' button, and compare what the memory maker thinks they should be set at, with what the BIOS actually set them at:
- and that's all there is to it! The only 'caveat' I know of: tRAS, as set by the BIOS, is for some reason, in some setups, displayed one count higher than the actual setting - dunno why, just be aware of it - if it 'looks' high, go back to the BIOS and check it - its probably correct there...
note³: SPDTool 0.63, from techPowerUp!, will show you every single piece of data, at the individual register level; but I seldom recommend it to anyone - first, 'raw' SPD data is in nanoseconds, not clock counts; your 'viewing program' or your BIOS do the conversion for you; with SPDTool, you must 'math it out' yourself; second, SPDTool is fully capable of writing an SPD! BEWARE! If you do this 'by accident', your DIMM may be ruined, and no longer bootable!
MemSet/CPU-Tweaker, EasyTune(X??), OverDrive, or BIOS: which should I use?
First, a bit about EasyTune. You likely want to stick with the same version of EasyTune that shipped, on the accompanying CD, with your board. I see this problem fairly often: someone has gone from gone from ET4, to ET5Pro, thinking they have 'upgraded', and get nothing but really peculiar problems! Because the functions of ET are so intimately 'tied into' your hardware and BIOS, the only way it can work is through having 'hooks' into 'stubs of code' in your BIOS. Therein lies the problem! Subsequent versions have 'hooks' for the system BIOS they ship with, but are seldom 'backward compatible'. There is a difference between 'version', and 'revision'! ET comes in, I believe, four versions: ET4, ET5, ET5Pro, and ET6. The current revisions are:
EasyTune4 - B04.101901
EasyTune5 - B7.0921.1
EasyTune5Pro - B7.1221.1
EasyTune6 - B10.0427.1
They are available here, and, once again, you want the highest available revision of whatever version that was shipped with your board...
Often, I am asked: "Should I do my overclock in EasyTune, or the BIOS?", or, "Do I want to have my memory setup in MemSet, or the BIOS?" Unequivocally, my answer is always the same - in the BIOS! While all of the above programs will allow you to modify BIOS or memory setup parameters - you really don't want them running on your system permanently! At issue is windoze' 'nefarious' ring zero...
An operating system is, at its core, an API - an application programmer's interface. If I want to write a windoze program, and I need to 'make a window', windoze knows what a 'window' is, and how to make one! All I have to do is 'pass a message' asking for one, and, with no further ado, windoze 'pops one up'; it gives me some options, in the message formatting, to tell it things like: "I want a non-resizeable window, with a minimize button, but no maximize button..." The reason I go into this detail is to make a point: because my access is 'limited' by the messaging format, the system itself is protected from my 'fiddling'! A program may simply fail, but it cannot, say, 'accidentally' write a number of bad clusters at random to the disk - as I am prevented from accessing that harware directly.
Obviously, however, there has to be a way to 'gain access' to that sort of control: say I want to write a disk defragger - I've got to have access to the disk, at the hardware level! In windoze, this access is provided by a 'programming layer' called 'ring zero'... Hardware drivers, by necessity, must access through this 'doorway'. The problem, however, is, that once in ring zero, a program can wreak infinite havoc - causing anything from 'interrupt loading lag' to total failure. If you load a program like EasyTune, that positively must 'do its magic' through ring zero - your system is at the mercy of its programmer! I recently wanted a program for 'ripping' DVDs to work on some hardware accelerated transcoding, and a buddy recommended SlySoft's AnyDVD - but, when it installed, it 'dumped a piece of itself' into ring zero - and that was the end of it! Uninstall, followed by a restore - I just don't allow it! There are a number of popular things that do this - lots of CD/DVD stuff, .iso image 'mounters', all verboten on a machine I depend on daily! There are advantages to ring zero - for instance, AutoCAD uses ring zero components to accelerate the hell out of its video access - and I'm willing to risk that they know what they're doing, but in general - nope!! I often recommend EasyTune as a 'quick & dirty' way to test individual parameters for an overclock (or MemSet/CPU-Tweaker for memory tweaking), but I would never trust them for 'day to day' operation ...
other content:
Part I - What memory is"
Part II - "What memory does"
Part III - "Evaluation and selection"
...the 'original debugger'...
Making it work!
Pretty much all modern computer systems have a 'central' clocking system, which allows them to coordinate their various subsystems which want to run at their own limits. This is referred to, in general, as a 'Bclk' (base clock). For 775 based systems, it's under "CPU Host Clock", and four times your host clock is your FSB (front system bus); Intel's 775 CPUs are rated at four FSBs: 800 (200 Bclk), 1066 (266 Bclk), 1333 (333 Bclk), and, at a grand a pop, 1600 (400 Bclk). For AMDs, it's also under "CPU Host Clock", and usually has a 'stock' setting of 200 MHz. For the Intel 1136/1566 platform (i3/i5/i7), it's actually called the 'Bclk', and has a 'stock' setting of 133MHz.
The various subsystems typically have their own multiplier, which, times the Bclk, sets their speeds. Here is a diagram of these 'subsystems' and their multipliers, for the i7:
There are a couple of "rules" to remember for the 'iCores' in reference to this diagram: first, the 'Uncore' multiplier must be at least twice the memory multiplier (and experience has shown that the processors 'like' odd uncore multipliers, so the best situation is uncore mult = [ 2 x memory mult ] + 1 ); second, the QPI/Vtt voltage must be within a half-volt of the Vdimm. The first is generally not an issue with i7's, as the uncore multipliers can be 'cranked' pretty well; however, it is an issue to be aware of with i5's - they have a 'locked' uncore (see below...), which, at 20x, also places a top limit on the memory multiplier, that you should be aware of when 'picking' memory for these - you can never get a memory multiplier higher than 10x, so any RAM speed above 1333 ('stock' 133 Bclk x 10 = 1333) will require raising the Bclk itself to accomplish... The second is also an issue with high-speed memory; most fast DDR3 is rated at 1.65V Vdimm, but the 'stock' setting for QPI/Vtt is typically 1.1V - that gives you a 'spread' of .55V: higher than the 'allowed' half-volt! Not really a problem though - so long as you are aware that you need to increase the Vtt when 'bumping up' the Vdimm. The i7 'spec maxes' for these (and people do run 'em higher - but, hey - it's your expensive puddle of molten silicon, do what you wish
!) are: Vttd & Vtta (same Vreg...) ≤ 1.35V; Vdimm ≤ 1.875! The 'nature' of multipliers...
For AMD, and 775 processors, the multipliers 'look' like decimal numbers - but they are not! You are not able to just 'dial in' any speed you want - they are fixed, integer-based divider networks, in the circuitry. For example the AMD's '5.33' setting is actually an 8:3 integer divider, meant to give you a nice, even 1066 RAM speed with the 'stock' 200MHz base clock, and the 6.66 (fundamentalists [:lorbat:5], beware!) is 10:3, which results in 1333 RAM. (Note - the math 'divides out' to one-half the 'displayed' RAM speed, as DDR is 'double data rate' - it transfers data on both the rising and falling 'edge' of its clock, meaning the physical clock speed is one-half the DDR 'rate'...)
For 775 processors and northbridges, the following table may make it clearer, as it shows both the actual multiplier ratios, as well as the process of progressively 'walking up' the frequencies/ratios, to allow DDR2-1066 to accommodate various Bclks:
'Locked' multipliers and 'Locked' multipliers!
Much like The difference between "Supported Speed", and "Supported Speed"! topic in Part III - "Evaluation and selection", most mutipliers reffered to as 'locked' are not actually - they are a range of adjustable multipliers that are 'capped' or 'top limited'; these are usually the Core Multilpliers cited in stating the CPU's 'standard speed'. An i3-540 is rated at 3.06 GHz, as the stock Bclk (133) times its max core multiplier, 23, gives you 3.059. You can use any lower multilplier at will. On the other hand, there are actually locked multipliers. For the i5 processors, the 'uncore' multipliers are locked at 20x - can't raise 'em, can't lower 'em!
Timings, 'sub-timings', and "why is this crap a secret?"
As previously discussed in Part I, DRAM is arranged in multi-dimensional 'arrays', and the need to 'activate' or change any one of these 'dimensions' incurs a physical cost in time - the 'latencies'. The main latencies are usually shown as: CAS-tRCD-tRP-tRAS. i.e., 7-7-7-21... Many of these 'dimension changes' or selections are referred to as 'strobes': the act of 'pulling an address line high' - so, we have:
The BIG FOUR!
■CAS: column address strobe; time betwixt the memory controller telling the RAM to access a column, and the data from that column being available at the RAM's outputs...
■tRCD: RAS to CAS delay; time between a row activate command, and a read/write command to that row...
■tRP: row precharge; time necessary to terminate access to an open row , and open access to the next row...
■tRAS: row address strobe; time needed to access a particular row of data in RAM, between the data request and the precharge commands...
And, from some manufacturers, WE CAN'T EVEN GET THESE! I won't name names here (however, be afraid - be very afraid!), but a couple 'makers' only give CAS timings for their products, and THAT'S IT!! [:bilbat:3] If everyone 'voted with their dollars', this would be cured within two months! Either they'd go out of business (which they so richly deserve), or, we'd get decent documentation - manufacturers, take your pick! Follow my policy: click on that NE 'manufacturer's links' tab - follow that 'product page' link... If they don't post decent technical data - what can you possibly expect their support to resemble?? Some can't even manage to have the link 'point to' the product
! I'm sorry; if you 'can't be bothered' to provide access to necessary manuals and relevant documentation, then I 'can't be bothered' to order your product - end of story!! OK - rant over...If you'd like to see some actual, detailed, specific tech docs, visit Micron: sample_doc | SPD_info | SPD_technote... ?
?Anyway, in addition to the 'big four', there are numerous other 'physical delays', linked to other aspects of 'physical access' to the RAM circuits themselves; all of these are important, and any one set wrong can 'bolix up' your whole memory set-up! Rather than try to detail all of these, I'll just reference a couple good pages at TweakTown, and Tweakers for further explanation; the best (so far - in view of available documentation) place to find these little tidbits about your particular RAM is in the SPD the DIMMs contain, discussed next...
SPD, EPP, XMP, and "can't we all just get along?"
The SPD on each DIMM (serial presence detect - I know - didn't make any sense to me either, until I stumbled across this: "early 72-pin SIMMs included 5 pins which provided 5 bits of parallel presence detect (PPD) data; the 168-pin DIMM standard changed to a serial presence detect to encode much more information") contains all the data your BIOS needs to configure your particular memory for use by your system, and sometimes more... It is a seperate, 'self-contained' subsystem: has a couple configuration pins [SA0 & SA2, pins 239 & 240], its own supply voltage [VddSPD, pin 238], its own clock [SCL, pin 120], and a single data line, SDA on pin 119 of the DIMM. This table of data is very precisely defined by JEDEC, and the data definitions can be seen here, at SimmTester, unless you want to 'struggle through' the actual JEDEC DDR3 SPD doc, here... Be aware, though, that there are at least nine 'addenda' to the SPD docs - 'annexes' A through J [:bilbat:7]! A number of utilities will also give you 'views', of varying completeness:
In addition to the 'basic', required data for the JEDEC standard clock speeds for your RAM, the SPD is allowed (but not required) to contain additional data sets for faster, non-standard speeds. However, in one of their little 'pissing contests', AMD (actually, originally nVidia and Corsair) have one data set, called an EPP - enhanced performance profile, for their extension; and Intel has another, different one, called XMP - extreme memory profile, for theirs! I, frankly, just don't get it: these extensions could, in theory, 'coexist', as the EPP occupies bytes 99-127 of the SPD 'space', while the XMP uses bytes 176–255; you could have both on every high-speed DIMM - but, I suppose the bits would form little green and blue warring 'camps' inside the modules!
I am currently unsure whether the recent crop of AMD chipsets/CPUs support the EPP extension at all... When I find out, I will update here - gotta read the AMD start-up sample stuff in 'pseudo-code', which will take a while - looks to be somewhat longer than Psalms! [:fixitbil:1]
'Sidestepping' XMP's limitations:
I don't know if this is an issue for most MOBOs, but, at least on GIGABYTES', enabling XMP - disables pretty much every other clocking and voltage adjustment! ^%$#! I've tried to come up with a slick way of conquering this, using the BIOS' CMOS parameter 'storage slots', but - it just ain't happening! Boils down to the fact that enabling XMP changes all the parameters instantaneously, rather that awaiting the next boot, as does disabling it - no way to 'get in between' to save the XMP memory parameters, without it being enabled, crippling everything else!
So - the 'clumsy workaround' (actually, only takes about five or eight minutes to 'dial-in' [:isamuelson:8] ):
■Put one DIMM in the slot recommended for 'single sticks' in the manual - just to make sure it works...
■Do a "Load Optimized" from the BIOS' main page, to get an initial 'good setup'; <F10> to save, exit, and reboot...
■Do an <F11> "Save to BIOS", naming the 'slot' someting like 'BaseLine' - now you can 'get back' in case of [:lorbat:6] ...
■Enable XMP; again, <F10> to save, exit, and reboot...
■Run a pass or two of MemTest (see below...) to verify functioning XMP setup...
■Go through your BIOS, and write down all relevant settings, including:
----> ALL memory timings, NOT JUST CAS-tRCD-tRP-tRAS, ALL of 'em!
----> 'Profile Vddr'*
----> 'Profile QPI/Vtt'*
----> 'Bclk' (remember, if your RAM is faster than 1333 with an i5, XMP will 'bump' your Bclk!*
----> Memory multiplier*
----> Uncore multiplier* (if applicable - n/a for i5's...)
■Disable XMP, once again, <F10> to save, exit, and reboot...
Now, finally, you're ready for the 'dial-in'! You have a list, primarily, of the full memory parameter set for your RAM's rated speed. Let's say we're looking at some DDR3-1600... The memory controller doesn't care if that's: a 133Bclk x 12 memory multiplier, or a 160Bclk x 10 memory multiplier, or 200Bclk x 8 memory multiplier; 1600 is 1600, and your 'parameter set' should work for any of 'em! All of the parameters above marked with * can be 'fiddled with'... Now's the time to decide where you want to go with your setup, how much overclocking, how much voltage/heat you'll commit to; it's a good time to double check that your 'Profile QPI/Vtt is 'comfortably' within the half-volt limit compared to the Vddr, and if it's 'close', bump it up a bit; see if you can get that uncore multiplier to the next integer above two times the memory multiplier; don't forget that if you're raising the Bclk, you'll want to lower the QPI multiplier to stay within the 'realm of the possible'. Dial in all your settings in the BIOS, do an <F11> 'save to BIOS', calling the 'slot' something like "MyXMPTry1", so you can 'get back here', do the <F10> save, exit, and reboot - and - the moment of truth! See if she boots! Also, another good time to run a pass or two of MemTest, just for confirmation...
If she looks good, power down, put in the other DIMM (for 1156), or the other two dimms (for 1366), and try again - and, another Memtest pass, if you please! At this point, however, limit your testing to two (or three) DIMMs - to run more than a DIMM per channel will likely take some futher adjustment...
Two DIMMs per channel 'adjustments':
Electrical impulses do not 'travel' instantaneously from point to point on your board. Much like the memory's latencies, there are finite 'time losses' for a signal to get 'from A to B'! As obviously, all your DIMMs can't be exactly the same distance from your memory controller (be it northbridge or CPU), the signalling will be 'skewed' to some of your DIMMs. The board designers rely on 'meanders', sort of 'maze-like' runs of circuit board traces, to try to make these lines as equal as possible; but, the 'meandering', itself, causes induced capacitance and inductance, which also changes the signal timing - so there's only so much that can be done... Some memory controllers are capable of storing certain timing parameters on a 'per DIMM' basis to try to accomodate these differences, and these are usually set 'in auto' by the BIOS/controller's 'training routines' (another good reason to stay withing the 'supported' guidlines from The difference between "Supported Speed", and "Supported Speed"! in Part III - "Evaluation and selection"); you are likely better off to not 'fiddle with' these - without access to about three thousand dollars and up worth of logic analyzer, it takes skill and luck to improve on these settings through trial and error (mostly - error)! Because of these 'per DIMM' differences, however, it should be apparent that the timing parameters need to be somewhat 'relaxed', or slowed, to allow for these signals to 'catch up' with each other... For many setups, increasing tRFC by roughly 10-15%, and checking that your Command Rate (actually, 'commands-per-clock' - whether your controller can issue a command each clock cycle, or only alternating clocks...) is set to 2 ('2T' or '2N', depending on your system), will take care of these 'skews'.
Another thing that multiple DIMMs per channel do is to cause increased 'loading' of the DIMM supplies themselves, as well as all the signal lines. This is why having more than one DIMM per channel usually requires additional voltage: from a tenth to a tenth-and-a-half of additional vMCH for northbridge-based controllers, to from a few hundreths to a tenth of extra vDIMM for CPU-based controllers. For some reason, OCZs seem to be particularly 'voltage-hungry', and may want to be run toward the top of the cited ranges...
Tweaking, testing, and tuning - practical techniques:
blah blah blah
Memtest Techniques:
First 'jewel of wisdom': there is "MemTest", and there is "Memtest86+"; the former has occasionally been known to be 'buggy' - the latter is the one you want! Current version: Memtest86+ v4.10 Extract the downloaded .zip file, "memtest86+-4.10.iso.zip", which will give you an .iso file: "mt410.iso"; 'burn' the .iso to a CD-Rom... If you are running any of the various 'flavors' of seven, the 'burner' is 'native' - simply right-click on the .iso file, select 'Open With' > 'Windows Disk Image Burner', check 'Verify Disk After Burning', 'Burn', and you're good; or, use the 'burner that came with your DVD/CD drive, either Roxio or Nero, or, if your drive, like several of mine, came only with a nifty piece of re-useable bubble-wrap, there are some free CD/DVD burners here... However you do the burn, the next step is to boot to it: you will either want to change the BIOS' "first boot device", on the "Advanced BIOS Features" page to 'CDROM', or use the 'press any key to boot to CDROM' prompt that appears when you put a bootable CD into the drive at boot time (which, I believe, is a 'standard feature' of all GB BIOS - allows you to run the 'XpressRecovery' function from your included driver disk) - for which you may need to enable the "USB Keyboard Support" item on the "Integrated Peripherals"...
Changelogs (in case you've never seen an actual one![:bilbat:7]) and general info are available at memtest.org; there is also a support forum at CanardPC.com, but, it is for Memtest issues only (i.e., bug reports and feature requests) - not help with your particular hardware/memory issues!
Not many people are aware that Memtest86+ comes in 'create a bootable USB key' and 'create a bootable floppy' flavors!
To make the 'bootable flash drive' flavor: extract the downloaded file, "memtest86+-4.10.usb.installer.zip" to a location you can remember [:lectrocrew:7], which will result in a single file: "Memtest86+ 4.10 USB Installer.exe"; double-click on that file, and it will 'launch' the following sequence:
In the first 'frame', you will need to select your drive, and check the 'format' item. I will tell you the same thing I mention in the Bootable Flash Drive Tutorial: "You can't accidentally format your hard drive with this thing, but I don't want to hear any whining about having erased poor, dead, Aunt Bessie's pictures from your camera's SD stick, or having formatted your iPod or USB back-up drive by mistake, so check that the first item 'points' to your actual flash drive - do it now!" The remaining 'frames' are pretty 'idiot-proof'; all that remains is to enter your BIOS, set your first boot device to 'USB-HDD', and the "Legacy USB storage detect" (later BIOS say "USB Storage Function") on the "Integrated Peripherals" page to "Enabled", and you should be ready to rock!
To make the 'bootable floppy' flavor: extract the downloaded file, "memtest86+-4.10.floppy.zip", again, to a location you can remember [:lectrocrew:7], which will result in a 'floppy' folder/directory containing these files:
dd.exe
install.bat
install64.bat
memtestp.bin
rawrite.exe
README.txt
Double-click on 'install.bat' if you are running 32-bit windoze; 'install64.bat' if you are running 64-bit windoze - no biggie here, if you 'pick' the wrong one, it'll politely 'tell you', as in frame 1:
If you get it right, it'll sequence through frame 2 to frame 3; all that remains is, once again, to enter your BIOS, set your first boot device to 'Floppy' this time, save, and reboot!
If you aren't interested in the 'gory details', you can just scroll through this, down to the next purple entry - Memtest Useage: (it will work perfectly fine for you, without any participation from you, beyond getting it 'launchable') but - folks often ask about individual tests, or just generally "what the hell does it do?" - so, I thought, this was the spot!
Memtest's Testing Philosophy [:isamuelson:8]
There are many good approaches for testing memory. However, many tests simply 'throw some patterns' at memory without much thought or knowledge of memory architecture or how errors can best be detected. This works fine for hard memory failures but does little to find intermittent errors. BIOS based memory tests are useless for finding intermittent memory errors.
Memory chips consist of a large array of tightly packed memory cells (see Part I - What memory is") , one for each bit of data. The vast majority of the intermittent failures are a result of interaction between these memory cells. Often writing a memory cell can cause one of the adjacent cells to be written with the same data. An effective memory test attempts to test for this condition. Therefore, an ideal strategy for testing memory would be the following:
■1. write a cell with a zero
■2. write all of the adjacent cells with a one, one or more times
■3. check that the first cell still has a zero
It should be obvious that this strategy requires an exact knowledge of how the memory cells are laid out on the chip. In addition there is a never ending number of possible chip layouts for different chip types and manufacturers making this strategy impractical. However, there are testing algorithms that can approximate this ideal.
Test Algorithms²
Memtest86 uses two algorithms² that provide a reasonable approximation of the ideal test strategy above. The first of these strategies is called moving inversions. The moving inversion test works as follows:
■1. Fill memory with a pattern
■2. Starting at the lowest address:
■----->◦check that the pattern has not changed
■----->◦write the patterns' complement
■----->◦increment the address
■----->◦repeat
■3. Starting at the highest address:
■----->◦check that the pattern has not changed
■----->◦write the patterns' complement
■----->◦decrement the address
■----->◦repeat
This algorithm² is a good approximation of an ideal memory test but there are some limitations. Most high density chips today store data 4 to 16 bits wide. With chips that are more than one bit wide it is impossible to selectively read or write just one bit. This means that we cannot guarantee that all adjacent cells have been tested for interaction. In this case the best we can do is to use some patterns to insure that all adjacent cells have at least been written with all possible one and zero combinations.
note²: Algorithm is 'loosely used', here - technically, an algorithm is a precise step-by-step plan for a computational procedure that begins with an input value and yields an output value in a finite number of steps; commonly, it is abused to represent simply 'any well-defined computational procedure'... [/i]
Caching, buffering, and 'out of order execution' will interfere with the moving inversions algorithm and make less effective. It is possible to turn off cache but the memory buffering in new high performance chips can not be disabled. To address this limitation a new algorithm, Modulo-X was created. This algorithm is not affected by cache or buffering. The algorithm works as follows:
■1. For starting offsets of 0 - 20 do:
■----->◦write every 20th location with a pattern
■----->◦write all other locations with the patterns' complement
■----->◦repeat above one or more times
■----->◦check every 20th location for the pattern
This algorithm accomplishes nearly the same level of adjacency testing as moving inversions but is not affected by caching or buffering. Since separate write passes, and the read pass, are done for all of memory we can be assured that all of the buffers and cache have been flushed between passes.
Regarding 'interpreting' individual tests, MemTest has this to say about that:
Individual Test Descriptions
Memtest86 executes a series of numbered test sections to check for errors. These test sections consist of a combination of test algorithm, data pattern and cache setting. The execution order for these tests is arranged so that errors will be detected as rapidly as possible. A description of each of the test sections follows:
■Test 0 [Address test, walking ones, no cache]
Tests all address bits in all memory banks by using a walking ones address pattern.
■Test 1 [Address test, own address]
Each address is written with its own address and then is checked for consistency. In theory previous tests should have caught any memory addressing problems. This test should catch any addressing errors that somehow were not previously detected.
■Test 2 [Moving inversions, ones & zeros]
This test uses the moving inversions algorithm with patterns of all ones and zeros. Cache is enabled even though it interferes to some degree with the test algorithm. With cache enabled this test does not take long and should quickly find all "hard" errors and some more subtle errors. This test is only a quick check.
■Test 3 [Moving inversions, 8 bit pattern]
This is the same as test one but uses a 8 bit wide pattern of "walking" ones and zeros. This test will better detect subtle errors in "wide" memory chips. A total of 20 data patterns are used.
■Test 4 [Moving inversions, random pattern]
This test uses the same algorithm as test 1 but the data pattern is a random number and its complement. This test is particularly effective in finding difficult to detect data sensitive errors. A total of 60 patterns are used. The random number sequence is different with each pass so multiple passes increase effectiveness.
■Test 5 [Block move, 64 moves]
This test stresses memory by using block move (movsl) instructions and is based on Robert Redelmeier's burnBX test. Memory is initialized with shifting patterns that are inverted every 8 bytes. Then 4mb blocks of memory are moved around using the movsl instruction. After the moves are completed the data patterns are checked. Because the data is checked only after the memory moves are completed it is not possible to know where the error occurred. The addresses reported are only for where the bad pattern was found. Since the moves are constrained to a 8mb segment of memory the failing address will always be less than 8mb away from the reported address. Errors from this test are not used to calculate BadRAM patterns.
■Test 6 [Moving inversions, 32 bit pattern]
This is a variation of the moving inversions algorithm that shifts the data pattern left one bit for each successive address. The starting bit position is shifted left for each pass. To use all possible data patterns 32 passes are required. This test is quite effective at detecting data sensitive errors but the execution time is long.
■Test 7 [Random number sequence]
This test writes a series of random numbers into memory. By resetting the seed for the random number the same sequence of number can be created for a reference. The initial pattern is checked and then complemented and checked again on the next pass. However, unlike the moving inversions test writing and checking can only be done in the forward direction.
■Test 8 [Modulo 20, ones & zeros]
Using the Modulo-X algorithm should uncover errors that are not detected by moving inversions due to cache and buffering interference with the the algorithm. As with test one only ones and zeros are used for data patterns.
■Test 9 [Bit fade test, 90 min, 2 patterns]
The bit fade test initializes all of memory with a pattern and then sleeps for 90 minutes. Then memory is examined to see if any memory bits have changed. All ones and all zero patterns are used. This test takes at least three hours to complete. The Bit Fade test is not included in the normal test sequence and must be run manually via the runtime configuration menu.
Memtest Useage:
Pre-assembly DIMM 'qualification':
The first thing I do, when I start a 'system assembly' project, is to lay the board out, on an insulated surface, near the case and power supply; install the power connectors, the vidcard, a case speaker, the minimum of front panel wires, the CPU and HSF, and one DIMM - and then 'power her up', just to verify 'the basics' are working. The very next step I undertake, is to do a "Load Optimized", hook up a DVD, set 'er up to boot from it, and run a copy of Memtest on just that DIMM, usually overnight... When I get up in the morning, I verify the test results were good - switch DIMMs (same slot), and 'let 'er rip' again; assuming two DIMMs, by late that afternoon, I have confirmed two 'healthy' memory modules! Then, and only then - time to proceed!
If you are planning to overclock, another useful step at this point is to 'qualify' your RAM for overclocking; as well as 'characterize' each DIMM. If you intend to use, or need to test the capability of the XMP on your DIMMs, this is the time to do it. If you're planning on using higher speeds, or lower latencies than your DIMMs are 'documented at', ditto!
The reason I recommend a "LoadOpt" before each test is to 'ferret out' the (slim) possibility of a defective SPD on a given module; each time you do the "LoadOpt" with a single DIMM, it forces the BIOS to 'read' the SPD, and set itself accordingly - with a bad SPD (incorrect or 'scrambled' data), the "LoadOpt" will fail to give a 'working' configuration - revealing the DIMM as bad. If, however, several DIMMs fail this test, you may have a bad memory controller - or, you may be damaging them through handling (you are wearing that 'anti-stat' bracelet, aren't you?)
Full memory setup verification:
Having done the 'pre-assembly qualification' gives you an advantage in the process of tuning/tweaking your memory - you know the DIMMs are good! Whether your memory setup procedure is simply doing a "Load Optimized" from the BIOS, enabling XMP, or the much more involved process of adjusting for two DIMMs per channel or 'hand' overclocking of your memory, when you are finished and happy with your setup, another couple of passes of Memtest is just the thing to ensure your board and CPU are 'happy with' your setup! If she doesn't pass - back to the drawing board - another round of 'tweaking' is in order...
'Hunting down' a bad DIMM:
Things fail! Memory is not immune. Electronics are prone to fail shortly after their first use - this is known as 'infant mortality'. Often, the first clue is the infamous BSOD; in addition, sudden resets during, or halts of, installations (both OS and program) can be an indicator of a memory failure. Some memory would also appear to 'age', causing a once-working setup to show errors that can be repaired by slightly raising the Vdimm, or increasing the timings... First thing you need to know when these symptoms rear their ugly heads is "do I have a bad DIMM?" Memtest will again tell you - what you need to do is simply return to the same procedure listed above, in Pre-assembly DIMM 'qualification': one DIMM at a time, "Load Optimized" before each, to verify each one's integrity.
MemSet/CPU-Tweaker Technique:
MemSet and CPU-Tweaker are a pair of invaluable programs from the French site 'Tweakers'; (once again, polish up that high-school French, s'il vous plaît!) they are 'two sides of the same coin'... Both are intended to allow you to 'fiddle' your memory timings while running, for testing purposes; MemSet (current version: MemSet 4.1) is made to work with older 775 systems whose memory controller in on the system's northbridge; CPU-Tweaker (current version: CPU-Tweaker 1.5) works with both AMDs, and Intels with memory controllers integrated on the processor die; don't worry too much about getting the right one - if you manage to try to use the wrong one, it'll politely suggest that you run the other! [:bilbat:5]
Now, like I said, these programs are made to let you 'diddle around' with your memory timings, and sub-timings, 'on-the-fly' - and you can do that (I'll discuss that particular use later...) - BUT - I've found a procedure that has 'discovered' the problems in a number of posters' RAM setups, in a pretty straghtforward and 'obvious' way - and here's the secret: both of these programs give you an excellent view of your 'currently set' timings, and also are able to display more of the SPD data on your DIMMs than any (but one³) other program I know of! It's pretty simple to open up either one, click on its 'SPD' button, and compare what the memory maker thinks they should be set at, with what the BIOS actually set them at:
- and that's all there is to it! The only 'caveat' I know of: tRAS, as set by the BIOS, is for some reason, in some setups, displayed one count higher than the actual setting - dunno why, just be aware of it - if it 'looks' high, go back to the BIOS and check it - its probably correct there...
note³: SPDTool 0.63, from techPowerUp!, will show you every single piece of data, at the individual register level; but I seldom recommend it to anyone - first, 'raw' SPD data is in nanoseconds, not clock counts; your 'viewing program' or your BIOS do the conversion for you; with SPDTool, you must 'math it out' yourself; second, SPDTool is fully capable of writing an SPD! BEWARE! If you do this 'by accident', your DIMM may be ruined, and no longer bootable!
MemSet/CPU-Tweaker, EasyTune(X??), OverDrive, or BIOS: which should I use?
First, a bit about EasyTune. You likely want to stick with the same version of EasyTune that shipped, on the accompanying CD, with your board. I see this problem fairly often: someone has gone from gone from ET4, to ET5Pro, thinking they have 'upgraded', and get nothing but really peculiar problems! Because the functions of ET are so intimately 'tied into' your hardware and BIOS, the only way it can work is through having 'hooks' into 'stubs of code' in your BIOS. Therein lies the problem! Subsequent versions have 'hooks' for the system BIOS they ship with, but are seldom 'backward compatible'. There is a difference between 'version', and 'revision'! ET comes in, I believe, four versions: ET4, ET5, ET5Pro, and ET6. The current revisions are:
EasyTune4 - B04.101901
EasyTune5 - B7.0921.1
EasyTune5Pro - B7.1221.1
EasyTune6 - B10.0427.1
They are available here, and, once again, you want the highest available revision of whatever version that was shipped with your board...
Often, I am asked: "Should I do my overclock in EasyTune, or the BIOS?", or, "Do I want to have my memory setup in MemSet, or the BIOS?" Unequivocally, my answer is always the same - in the BIOS! While all of the above programs will allow you to modify BIOS or memory setup parameters - you really don't want them running on your system permanently! At issue is windoze' 'nefarious' ring zero...
An operating system is, at its core, an API - an application programmer's interface. If I want to write a windoze program, and I need to 'make a window', windoze knows what a 'window' is, and how to make one! All I have to do is 'pass a message' asking for one, and, with no further ado, windoze 'pops one up'; it gives me some options, in the message formatting, to tell it things like: "I want a non-resizeable window, with a minimize button, but no maximize button..." The reason I go into this detail is to make a point: because my access is 'limited' by the messaging format, the system itself is protected from my 'fiddling'! A program may simply fail, but it cannot, say, 'accidentally' write a number of bad clusters at random to the disk - as I am prevented from accessing that harware directly.
Obviously, however, there has to be a way to 'gain access' to that sort of control: say I want to write a disk defragger - I've got to have access to the disk, at the hardware level! In windoze, this access is provided by a 'programming layer' called 'ring zero'... Hardware drivers, by necessity, must access through this 'doorway'. The problem, however, is, that once in ring zero, a program can wreak infinite havoc - causing anything from 'interrupt loading lag' to total failure. If you load a program like EasyTune, that positively must 'do its magic' through ring zero - your system is at the mercy of its programmer! I recently wanted a program for 'ripping' DVDs to work on some hardware accelerated transcoding, and a buddy recommended SlySoft's AnyDVD - but, when it installed, it 'dumped a piece of itself' into ring zero - and that was the end of it! Uninstall, followed by a restore - I just don't allow it! There are a number of popular things that do this - lots of CD/DVD stuff, .iso image 'mounters', all verboten on a machine I depend on daily! There are advantages to ring zero - for instance, AutoCAD uses ring zero components to accelerate the hell out of its video access - and I'm willing to risk that they know what they're doing, but in general - nope!! I often recommend EasyTune as a 'quick & dirty' way to test individual parameters for an overclock (or MemSet/CPU-Tweaker for memory tweaking), but I would never trust them for 'day to day' operation ...
Facebook
Twitter
Instagram