memtest: How long?
Moderators: NeilBlanchard, Ralf Hutter, sthayashi, Lawrence Lee
memtest: How long?
I've just finished putting together my first computer and, as was suggested a few times in these forums, tried running memtest to check if everything is working. Running the program from floppy my screen showed endless rows of 0400's and 1000's. I started at 10 pm and at 4 pm the following day that was still the only thing showing on the screen. I stopped the program because I needed the computer for a bandrecording.
Is memtest normally taking this long and should I practice more patience or does it mean there's something wrong?
System specs: Abit nf7-s, Barton 2500+, 2*512mb 3200 memory, radeon 9800pro 128mb.
Is memtest normally taking this long and should I practice more patience or does it mean there's something wrong?
System specs: Abit nf7-s, Barton 2500+, 2*512mb 3200 memory, radeon 9800pro 128mb.
-
- Posts: 18
- Joined: Mon Mar 08, 2004 4:15 pm
Did you run the old memtest or the updated one?
When it boots it should look like this: http://www.memtest.org/pics/nf2-big.gif
When it boots it should look like this: http://www.memtest.org/pics/nf2-big.gif
It's 86+, version 1.11 Pre-Compiled package for floppy so the updated version. It didn't look anything like it .
It looked like this:
0400
1000
0400
0400
0400
0400
1000
Not in this particular order and the numbers were running on the left-side of the screen from bottom to top. The rest of the screen was black.
The system seems to be running fine though so any problems there are can not be very big....I hope .
Any suggestions?
It looked like this:
0400
1000
0400
0400
0400
0400
1000
Not in this particular order and the numbers were running on the left-side of the screen from bottom to top. The rest of the screen was black.
The system seems to be running fine though so any problems there are can not be very big....I hope .
Any suggestions?
Sorry for getting my priorities wrong. I will apologise humbly to my computer and promise it to never use it again as a tool in my live . I will, from now on, treat it as an individual being.m0002a wrote:You needed the computer for a band recording??? You have your priorities all mixed up. You should run the memory test forever. That is the only way you will know that your computer is functioning properly.
-
- SPCR Reviewer
- Posts: 8636
- Joined: Sat Nov 23, 2002 6:33 am
- Location: Sunny SoCal
Looks like you're getting millions and millions of errors if that's all that's showing on your screen. There's a key that toggles between "scroll" and "non-scroll". I keep it set at "non-scroll" so I can see the main part of the Memtest86 screen.peerke wrote:It's 86+, version 1.11 Pre-Compiled package for floppy so the updated version. It didn't look anything like it .
It looked like this:
0400
1000
0400
0400
0400
0400
1000
Not in this particular order and the numbers were running on the left-side of the screen from bottom to top. The rest of the screen was black.
The system seems to be running fine though so any problems there are can not be very big....I hope .
Any suggestions?
So what do you do about your memory errors?
- Go into the BIOS and check your memory settings. Make sure that everything is set correctly. Your memory should have a SPD rating (something like "2-3-3") and you need to make sure that, among other stuff is set correctly in the BIOS. If you try to run your memory faster than it is rated for that can cause errors.
- If you're sure your settings are good, pull out both sticks and reseat them. Make sure they're seated very firmly in their slots! Run Memtest86 again. If you're still getting errors, pull out one stick and test each stick by itself.
- What brand and type of memory are you using? "No-name" generic memory has very variable quality and a higher propensity for errors than quality, brand name memory like Crucial, Kingston, Corsair etc. Can you easily return it to where you bought it?
- When you do get Memtest86 running with no errors, let it run for at least 12 hours. It will keep looping over and over until you manually stop it.
-
- Posts: 38
- Joined: Mon May 12, 2003 1:24 pm
- Location: Barcelona
Thank you very, very much. That put me on the right track. Here's the story:BarCodeBlack wrote:Now.....if memory serves my right, I've had this same problem when I first started using memtest86 a few years ago
As it turned out, it was just a corrupt diskette. I'd suggest finding another floppy diskette from somewhere and try again.
I downloaded memtest 86+ v1.11 from the internet onto my (sony)laptop computer that is connected to the internet. The plan was to create the boot-floppy on the laptop and run the program on my newly built desktopcomputer that isn't connected to the internet, yet.
I first tried two new nashua diskettes both of which failed to work . The next diskette was a used sony that showed its old files on the laptop. This one also wouldn't work having tried it three times . I then reformatted the diskette on the desktop and put it back in the laptop. It showed up being unformatted! I reformatted again on the laptop and the desktop showed it as being unformatted!
This suggested that the diskette-drives were not as compatible as two sony drives should be . Therefore I tried the following: I burned the unzipped files to a CD and placed that in the desktop-computer. I unzipped the files on the desktop, put in the used but locally reformatted diskette and ran the program to create a boot floppy. I rebooted and hey presto; the program is running beautifully
This was an interesting learning proces. Thanks for the suggestions
Hey Ralf,Looks like you're getting millions and millions of errors if that's all that's showing on your screen. There's a key that toggles between "scroll" and "non-scroll". I keep it set at "non-scroll" so I can see the main part of the Memtest86 screen.
So what do you do about your memory errors?
- Go into the BIOS and check your memory settings. Make sure that everything is set correctly. Your memory should have a SPD rating (something like "2-3-3") and you need to make sure that, among other stuff is set correctly in the BIOS. If you try to run your memory faster than it is rated for that can cause errors.
- If you're sure your settings are good, pull out both sticks and reseat them. Make sure they're seated very firmly in their slots! Run Memtest86 again. If you're still getting errors, pull out one stick and test each stick by itself.
- What brand and type of memory are you using? "No-name" generic memory has very variable quality and a higher propensity for errors than quality, brand name memory like Crucial, Kingston, Corsair etc. Can you easily return it to where you bought it?
- When you do get Memtest86 running with no errors, let it run for at least 12 hours. It will keep looping over and over until you manually stop it.
Thanks for your reaction. I've learned to value your comments and suggestions very highly. I had a nice little adrenaline rush reading your post but as you can see above, the program is running now and I will leave it to run for at least twelve hours, as per your suggestion.
Depending on the outcome I may set the memory timings at more stable values or even put the sticks (kingston, by the way) in other slots. If that failes, I'll return them to my reseller. I've bought everything locally, so that returning would not become a big problem, but I hope it won't come to that. I'm always happy to take my bike (=not a motorcycle but a human-powered vehicle ) to cover the distance of 20 miles (+20 miles back) to my favourite computershop to buy new hardware, but I'm sure returning faulty parts won't be as enjoyable .
Here's an update on my experience with memtest:
Since my last post the program has been running for 48 hours and not one single failure . So the settings are stable and I can start some torturetests on the rest of the system. I think I'll try Prime95. Have to do a little research to find out if thats the best option.
Since my last post the program has been running for 48 hours and not one single failure . So the settings are stable and I can start some torturetests on the rest of the system. I think I'll try Prime95. Have to do a little research to find out if thats the best option.
Here's an update on my experience with memtest:
Since my last post the program has been running for 48 hours and not one single failure . So the settings are stable and I can start some torturetests on the rest of the system. I think I'll try Prime95. Have to do a little research to find out if thats the best option.
Since my last post the program has been running for 48 hours and not one single failure . So the settings are stable and I can start some torturetests on the rest of the system. I think I'll try Prime95. Have to do a little research to find out if thats the best option.
-
- *Lifetime Patron*
- Posts: 1288
- Joined: Sat Oct 25, 2003 3:21 pm
- Location: 15143, USA
- Contact:
Memtest+ (1.11 and later)
- 24 hours has been a safe testing time for me. Often memory errors show up in a couple of hours, sometimes it takes up to eight hours (especially if overclocking, driving near marginal stability)
- If you get lots of consecutive errors (filling up the screen), then you are using incompatible memory sizing routine with your motherboard. These errors are NOT real, you need to change the memory sizing routine in Memtest:
http://www.memtest86.com/#trouble
- Memtest is not a end all be all memory sub-system stability tester. I once ran it for 2 consecutive weeks in a row with not a single error. However, the system failed in 15 minutes in Prime95/Torture test/blend.
Prime95
- This is my 2nd personal favourite. If I can run the system for 24 hours stabe in Torture test (not normal calculation!), then I think the memory sub-system stable (sans 3D graphics, but that's another matter).
- If you get errors in this and are not using an old version of Prime or very new/unknown chipset/cpu then it is highly likely that you have a stability system. Even if your system is 24/7 on and you don't seem to notice any problems. Some of the most peculiar errors I've seen have all gone away once I managed to make my system Prime95 stable. I had programs quitting on me randomly/rarely without any error. System never crashed (no BSDO) and I could run all sorts of 3D benchmarks in a loop for days. However, once I fixed FSB/mem latencies to make the system Prime95 stable, all of the rest of the small oddities vanished.
- 24 hours has been a safe testing time for me. Often memory errors show up in a couple of hours, sometimes it takes up to eight hours (especially if overclocking, driving near marginal stability)
- If you get lots of consecutive errors (filling up the screen), then you are using incompatible memory sizing routine with your motherboard. These errors are NOT real, you need to change the memory sizing routine in Memtest:
http://www.memtest86.com/#trouble
- Memtest is not a end all be all memory sub-system stability tester. I once ran it for 2 consecutive weeks in a row with not a single error. However, the system failed in 15 minutes in Prime95/Torture test/blend.
Prime95
- This is my 2nd personal favourite. If I can run the system for 24 hours stabe in Torture test (not normal calculation!), then I think the memory sub-system stable (sans 3D graphics, but that's another matter).
- If you get errors in this and are not using an old version of Prime or very new/unknown chipset/cpu then it is highly likely that you have a stability system. Even if your system is 24/7 on and you don't seem to notice any problems. Some of the most peculiar errors I've seen have all gone away once I managed to make my system Prime95 stable. I had programs quitting on me randomly/rarely without any error. System never crashed (no BSDO) and I could run all sorts of 3D benchmarks in a loop for days. However, once I fixed FSB/mem latencies to make the system Prime95 stable, all of the rest of the small oddities vanished.
-
- SPCR Reviewer
- Posts: 8636
- Joined: Sat Nov 23, 2002 6:33 am
- Location: Sunny SoCal
That's probably because Prime95 was testing the stability of your CPU, which apparently had some sort of a problem, and Memtest86 tests the stability of your memory subsystem, which was running fine. They're two different things.halcyon wrote:- Memtest is not a end all be all memory sub-system stability tester. I once ran it for 2 consecutive weeks in a row with not a single error. However, the system failed in 15 minutes in Prime95/Torture test/blend.
And neither of them leans on your video subsystem at all. For that you need something like 3Dmark.
In otherwords, neither Memtest86, nor Prime95, or even 3Dmark for that matter, are "all-inclusive" stability testing apps. They each test a diffenent part of your hardware and don't overlap very much. You really need to run all three of them to be reasonably sure that your system is stable.
I agree with Ralf Hutter
With one exception, however On intense GPU overclocking i found running Q3 demos in loops best stress for GFX card, because the 3DMarks are far from optimized and did not push the GPU well, especially if you have weak CPU (weak cpu = anything bellow 3.2Ghz and FSB 220MHz+++)
It's true.
I got demo and benchmark in 3DMark03 finished at CORE clock 310Mhz, however Q3 instantly lock up I have go all the way down to 285Mhz (orginal is 250) to make it stable - runing Q3 demo in loop is easy:
First open concole, then write:
com_maxfps 0 -> unlimited FPS - make sure you have vertical synchornization set to OFF into your GFX card cotrol settings
set again "demo four;set nextdemo vstr again" -> this set the loop, it set variable again that play demo four and then execute theirself again - GO TO programming example of BAD programming )
/vstr again -> and it starts and never stop
Happy torturing of your GPU, dudes!
(demo four are included in Q3 installation by default, into the pak file )
With one exception, however On intense GPU overclocking i found running Q3 demos in loops best stress for GFX card, because the 3DMarks are far from optimized and did not push the GPU well, especially if you have weak CPU (weak cpu = anything bellow 3.2Ghz and FSB 220MHz+++)
It's true.
I got demo and benchmark in 3DMark03 finished at CORE clock 310Mhz, however Q3 instantly lock up I have go all the way down to 285Mhz (orginal is 250) to make it stable - runing Q3 demo in loop is easy:
First open concole, then write:
com_maxfps 0 -> unlimited FPS - make sure you have vertical synchornization set to OFF into your GFX card cotrol settings
set again "demo four;set nextdemo vstr again" -> this set the loop, it set variable again that play demo four and then execute theirself again - GO TO programming example of BAD programming )
/vstr again -> and it starts and never stop
Happy torturing of your GPU, dudes!
(demo four are included in Q3 installation by default, into the pak file )
I agree with Ralf - for the most part.
Both tests do in fact stress CPU, memory controller and the memory DIMMs themselves.
The authors of the respective utilities admit that is is not possible to pinpoint if an error in calculation is caused by the CPU, memory controller or the memory itself.
A case in point being a test where I ran the CPU well within thermal limits and it would pass Memtest but fail Prime95.
Upong lowering FSB, but keeping the CPU clock speed same (higher multi) I was able to get rid of the Memory problems in Prime.
That is, CPU stayed at exact same temp/speed, but only FSB and memory latencies were lowered.
So, it pays to test with a lot of software. I agree on that.
Also, add CPU Burn to that suite.
Both tests do in fact stress CPU, memory controller and the memory DIMMs themselves.
The authors of the respective utilities admit that is is not possible to pinpoint if an error in calculation is caused by the CPU, memory controller or the memory itself.
A case in point being a test where I ran the CPU well within thermal limits and it would pass Memtest but fail Prime95.
Upong lowering FSB, but keeping the CPU clock speed same (higher multi) I was able to get rid of the Memory problems in Prime.
That is, CPU stayed at exact same temp/speed, but only FSB and memory latencies were lowered.
So, it pays to test with a lot of software. I agree on that.
Also, add CPU Burn to that suite.
-
- Posts: 587
- Joined: Fri Aug 01, 2003 10:45 pm
- Location: North Billerica, MA, USA
- Contact:
On my last job, we used a proprietary board that was essentially a P-II w/ some other goodies, using a standard chipset and normal SIMM's. We used a SCSI subsystem, and part of our system testing was a 12 hour (minimum) test that consisted of writing a file repeatedly to the drive until the filled, erasing the copies, etc. We had a frequent problem with some boards rebooting on us that the vendor was unable to fix, not good in a system spec'd for 5 9's uptime I eventually identified and turned off all the watchdog timers that were rebooting the boards so as to preserve the primary failure, which turned out to be a panic dump caused by a parity error. Swapping SIMM's cured the error consistently, and putting a suspect SIMM in a good board would cause it to fail. The suspect SIMM's would test as good on all three of our SIMM testers, and would run MEMTEST86 for as long as we wanted, without errors (over a week...) Several other testing utilities also failed to find the problem.
One of the things I've also observed over the years is that just BOOTING a *nix is often more of a strain on a system than running any MS based diagnostic utility. Among many folks I know, the most effective torture test for a machine that beats on the memory, hard drive and CPU is to simply write a script to do repetetive Linux kernel compiles. If you really want to be brutal, start multiple concurrent threads and keep adding them until something breaks...
Gooserider
One of the things I've also observed over the years is that just BOOTING a *nix is often more of a strain on a system than running any MS based diagnostic utility. Among many folks I know, the most effective torture test for a machine that beats on the memory, hard drive and CPU is to simply write a script to do repetetive Linux kernel compiles. If you really want to be brutal, start multiple concurrent threads and keep adding them until something breaks...
Gooserider
funny you should mention regarding memory and unix Gooserider, because i just went through that same scenario just before reading this! in fact, it was two days of frustration when installing solaris on an old machine (P3 500, scsi, not overclocked) i cobbled together kept on randomly panic'ing during the install (including linux) or sometimes on reboot .. and after much hardware swapping and utilities verification, the last thing i decided to touch was memory because after all, memtest v3.0 -- the default suite of tests at least-- ran just fine! well, turns out it was one particular bad dimm.
suffice it to say, i thought this was just an isolated incidents of the right bits being coincedentally touched, but after reading your experience, i will definitely keep the "*nix install test" in mind!
suffice it to say, i thought this was just an isolated incidents of the right bits being coincedentally touched, but after reading your experience, i will definitely keep the "*nix install test" in mind!
ok, i take that back -- maybe memtest really is saying the truth as far as the physical health of the memory is concerned. it's probably more of compatability of modules or timing issue with a system configuration (including other modules) because i just bought a mushkin dimm to replace the supposedly "bad" one. well that also resulted in a very reproducable panic early on when installing solaris. so i tried just the mushkin module alone, where originally, it was in the middle of two other modules in the system, and that worked! so on that hunch, i went back and tried the "bad" dimm by itself, and of course it worked. so now my dilema is finding dimms that are "compatible" with my existing dimms or just get rid of the existing ones and go with all the same brand/model.