注册 登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

zorksylar

Nothing is impossible , if distributed.

 
 
 

日志

 
 

[zz]memtest测试存储性能  

2012-02-28 13:14:35|  分类: linux学习 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
转自:http://www.overclockers.com/forums/showthread.php?t=409152

What's Memtest  

For you new people and rest of you guys that wonder what memtest is, well its a RAM reliability tester. It evaluates the ability of your computers memory to store and retrieve data. A correctly functioning computer should be able to do both these tasks with 100% accuracy day in and day out. A computer that fails these tests, perhaps because of old hardware, damaged hardware, or poorly configured hardware, will be less stable and crash more often. By running MemTest, you can ensure that your computers RAM is correctly functioning. Unlike other memory checking software, MemTest is designed to find all types of memory errors including intermittent problems. Therefore, it needs to be run for several hours to truly evaluate your RAM. MemTest works with any type of memory.

The original program, Memtest 86, was written by Chris Brady and the "+" version is its legacy by other members of the x86-secret team. Memtest86 (the original) worked great but wasn't updated very often to reflect changes in chipsets or processors. Memtest86+ is updated quite often (sometimes monthly) and generally supports the latest hardware.


Some other things that you should keep on your mind!

Memory can break. Faulty memory can sometimes cause only certain programs to crash. Sometimes faulty memory can prevent the computer from booting. Memory errors, not prevalent during default settings, can sometimes inhibit overclocking ability.

Memory can be brand new and be faulty. It also can function normally for a period of time then, unpredictably, fail or exhibit errors.


First things first

Memtest86+ does not run in Windows. It uses a tiny version of Linux as its OS, just enough to run the program and generate a display a simple GUI. It is a small program and can easily extract to a floppy disk or can be run from a bootable USB key or CD.


How to create a bootable disk/floppy

Even though its possible to boot it off the USB its not recommended since it's way more complicated. Generally most people have either CD or Floppy drive which is much easier to use.

First thing you should get is the Boot Disk Maker
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You'll see the latest version of the boot disk maker at the top of the list. At the memtest page you will see few choices and they can look confusing. The ones that you will need are following:

To create a bootable CD then choose the Pre-Compiled Bootable ISO (.zip)!

To create a bootable floppy then choose the Pre-Compiled package for Floppy (DOS - Win)!


Making the floppy

Unzip the file and run the "runme.bat" file. It will run a batch program that prompts for a blank disk. Insert a blank disk and it will make a bootable floppy with Memtest on it. All you need to do is boot off of that floppy and memtest will start to run.  


Making the CD

There's an ISO file inside of the downloaded zip file. You can use many popular CD burning packages such as Nero or Roxio to burn the ISO to a blank CD-R. Remember that you need to burn this iso file as a disk image. DON'T write the ISO file onto a blank CD as that will do nothing. You need to consult your particular CD burning program's documentation to learn how to burn a CD image on to a disk. Basically, the ISO is a "package" of what the CD looks like compressed into a file for easy transport. It contains the boot sector and the directory tree of the disk, so you can understand why it needs to be "extracted" and written to the disk.

In NERO an image file can be burnt by choosing BURN IMAGE in the RECORDER menu.





Once the floppy is created or the ISO image burned then the computer can boot off the CD or floppy and memtest will automatically start to run.


When the memtest starts basically let it run and your main goal is to get pass (usually around 10 but more is better for ultimate stability). 



By request: It is recommended that you run all of the tests in the sequence since they each do/test different things:

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 pat]

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]

Test 4 uses the same algorithm as test 1 but the data pattern is a random number and it's 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 pat]

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 3 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. 


Bellow I will give you the key sequence for selecting the test:

1. First press C

2. then 1

3. then 3

4. and finally select the test that you want to run

5. press Enter

6. and then 0 to get it running

Quote:
Originally Posted by g0dM@n
The newer versions are:
Push C + Push 1 + Push 3 + Push Test#

Older versions (which Eva showed shortcuts for) are:
Push C + Push 2 + Push 5 + Push Test#

1, 3, test# doesn't work on the older memtests. I noticed this when I got my DFI NF4 the first time. I tried C, 2, 5, 5 for test#5 and it wasn't working out until I noticed that it was set up differently.

What to do if Memtest 86+ says there are errors?

If you have errors then there are a couple of things to check first.

First, if you have multiple sticks of ram, test each one at a time by physically pulling all RAM except for the module you wish to check. Test each good ram module in every slot to confirm if you have a faulty module or a faulty DIMM slot. Yes...DIMM slots can fail too.

If the memory is under warranty then it can be RMA'd to the supplier or manufacturer. It's a good idea to note any of the Memtest results in the RMA form.

If you are overclocking then too high FSB settings can generate memory errors as can under-volting RAM. Try backing down your OC or bumping the voltage to your RAM to see if that clears up the error. 

Another thing that could help is fine tunning the timings but that depends on the chips used on your RAM. The most usual suspects is the RAS to CAS and CAS Latency. Increasing these will give you better stability but it will degrade your performance so you need to keep that in mind. Increasing Vdimm helps also but this differentiates from chip to chip since some can take higher voltages then the others. In this case make sure that you have your RAM active cooled to prevent it from overheating which in most cases causes the errors in first place. Cooler the RAM better the stability and performance as well.

Please be aware that not all errors reported by Memtest86 are due to bad memory. The test implicitly tests the CPU, L1 and L2 caches as well as the motherboard. It is impossible for the test to determine what causes the failure to occur. However, most failures will be due to a problem with memory module. When it is not, the only option is to replace parts until the failure is corrected.

Once a memory error has been detected, determining the failing SIMM/DIMM module is not a clear cut procedure. With the large number of motherboard vendors and possible combinations of memory slots it would be difficult if not impossible to assemble complete information about how a particular error would map to a failing memory module. However, there are steps that may be taken to determine the failing module. Here are four techniques that you may wish to use:

1) Removing modules
This is simplest method for isolating a failing modules, but may only be employed when one or more modules can be removed from the system. By selectively removing modules from the system and then running the test you will be able to find the bad modules. Be sure to note exactly which modules are in the system when the test passes and when the test fails.

2) Rotating modules
When none of the modules can be removed then you may wish to rotate modules to find the failing one. This technique can only be used if there are three or more modules in the system. Change the location of two modules at a time. For example put the module from slot 1 into slot 2 and put the module from slot 2 in slot 1. Run the test and if either the failing bit or address changes then you know that the failing module is one of the ones just moved. By using several combinations of module movement you should be able to determine which module is failing.

3) Replacing modules
If you are unable to use either of the previous techniques then you are left to selective replacement of modules to find the failure.

4) Avoiding allocation
The printing mode for BadRAM patterns is intended to construct boot time parameters for a Linux kernel that is compiled with BadRAM support. This work-around makes it possible for Linux to reliably run with defective RAM. For more information on BadRAM support for Linux, sail tohttp://home.zonnet.nl/vanrein/badram

Sometimes memory errors show up due to component incompatibility. A memory module may work fine in one system and not in another. This is not uncommon and is a source of confusion. In these situations the components are not necessarily bad but have marginal conditions that when combined with other components will cause errors.

There have been numerous reports of errors with only tests 5 and 8 on Athlon systems. Often the memory works in a different system or the vendor insists that it is good. In these cases the memory is not necessarily bad but is not able to operate reliably at Athlon speeds. Sometimes more conservative memory timings on the motherboard will correct these errors. In other cases the only option is to replace the memory with better quality, higher speed memory. Don't buy cheap memory and expect it to work with an Athlon! On occasion test 5/8 errors will occur even with name brand memory and a quality motherboard. These errors are legitimate and should be corrected.

In the vast majority of cases errors reported by the test are valid. There are some systems that cause Memtest86 to be confused about the size of memory and it will try to test non-existent memory. This will cause a large number of consecutive addresses to be reported as bad and generally there will be many bits in error. If you have a relatively small number of failing addresses and only one or two bits in error you can be certain that the errors are valid. Also intermittent errors are without exception valid. Frequently memory vendors question if Memtest86 supports their particular memory type or a chipset. Memtest86 is designed to work with all memory types and all chipsets. Only support for ECC requires knowledge of the chipset.

All valid memory errors should be corrected. It is possible that a particular error will never show up in normal operation. However, operating with marginal memory is risky and can result in data loss and even disk corruption. Even if there is no overt indication of problems you cannot assume that your system is unaffected. Sometimes intermittent errors can cause problems that do not show up for a long time. You can be sure that Murphy will get you if you know about a memory error and ignore it.

Memtest86 can not diagnose many types of PC failures. For example a faulty CPU that causes Windows to crash will most likely just cause Memtest86 to crash in the same way. 

Quote:
Originally Posted by eva2000
memtest ain't 100% but you can use memtest to guage the max possible FSB/MEM which is the top limit of what you can expect... since i don't think i've ever experienced windows 100% stability and error free at a speed higher than the highest memtest passable speed

therefore

max FSB/MEM speed (100% windows error free/stability) <= max FSB/MEM speed (memtest error free)

test #1 - 4
are cpu fsb speed and or vcore related (meaning lowering fsb or increasing vcore saw errors in these tests disappear)

test #5
prior to 865/875 boards - memory speed, timings and vdimm related (meaning altering mem speed, timings and/or vdimm saw errors in this test disappear)

test#6
with 865/875 boards bigtoe has said related to cycle time (tras) in cpuz which i sort of confirmed with my current testing

note: prior to 865/875 boards, i've never had memory errors in test #6 only since these new boards have i experienced test #6 errors

test #7
not sure very rarely have i experienced errors

extended test
test #8 is a more intensive version of test #5

most memory related errors pop up at test #5 hence i like looping test #5 for memory testing for 12-24hrs after 1-4hr general standard loop of test #1-7

i like to loop test #3 and/or #4 for cpu related issues

I follow it up with at least goldmem 5.07:

2 quick test loops
+
2-4 full standard loops <-- can take forever trying doing it with 4 x 512mb xms3200c2

to loop a particular test

n memtest hit keyboard key

C -> 2 -> 5 and then select a test number to loop

spacebar = locks screen so it shows the very first error so where ram first errors out

enter key = unlocks screen

this is done, before i even load windows... if theres errors in above stage memtest or goldmem stages, i don't even bother loading windows or benching

i realise not everyone has time to do this but i like to know exactly what i get (ram) and how it performs

some people just load windows and see if it crashes or is stable... but you can't see why it crashes or isn't stable - is it the memory or cpu related etc

it makes it easier to test when you have more than 1 pc and a kvm switch to control 2-4 pcs from the same console

  评论这张
 
阅读(742)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018