Winchester + Prime95 = no go?
 

It's all here -
[url]http://www.xtremesystems.org/forums/showthread.php?t=46885&page=1&pp=25[/url]

George, are you sure there is no bug? This would mean that there are A LOT OF earlier week Winchesters that DO NOT pass Prime95 blend test even at STOCK speeds! And we all know what that means, right :shock: AMD would have to replace A LOT of faulty CPUs

:help:

thought i would post my 10 sence im waiting activation but here is what i will be posting add revisions as needed.

Posted by saaya post# 70
so memtest works but prime fails? then it sounds like a program related error, i never heard that memory passes metest but fails in prime before... weird...


---- Memtest doesnt test a cpu the way prime95 tests it actually memtest doesnt even do anything really with the cpu. prime95 checks your answer agnist the real known correct answer


Posted by WICKeD post# 77
I think even a stock system is going to give small errors after continuous usage. Prime is probably the best test for stability, but I think there should be a limit on it. Most people are not going to run their system @ 100% for over 8 hours, without letting it cool. Unless you fold or do media encoding, I'd say it's fair to claim stability if it can run overnight. That's just my opinion.


----to answer your comment on limit if you can go over 8 hours on prime 95 tehres something not right prime95 is running longterm on a lot of computers.
[url]http://www.mersenne.org/primenet/status.shtml[/url] go to bottom of the page you will see a hourly updated info section of the project also susgest you visit 15 minutes after hour because server takes a few minutes to rewrite new data.


Posted by Byron post# 119
WiCKeD,
my mem is fine and my board, can run dual channel at same speeds no problems.
Must be prime problem, because system is rock solid, can run all benchmark programs etc, or bad mem controller... but if the mem controller is bad, then why it my system is stable?!

---- prime 95 tests the whole cpu some programs dont totally test it prime 95 looks for the smallest problem if there is a problem it will proibily be found. just because a system is stable doesnt mean it is truely stable. if you dont run proc 100% all the time then so be it but if prime 95 finds a bug then you know there must be something wrong prime 95 does advanced calculations and checks the answer your computer outputs agnist a true well tested and known answer.


Posted by [ R2 ] pst# 136
I dont know why so many ppl are so concerned with p95, just dont use it, its that simple.
There are other programs to test stability of your cpu and etc...

---- yes but they dont do a complete stress test.


Posted by Paa' post number 177
I would think there was'nt anything wrong at all with prime95 just the fact that a64's have built in memory controllers on the cpu means prime can fail for either and it's hard to tell..

i need to up my vcore to reach 250 fsb.. even with a below default speed.

that beta prime95 im running seem's to do one thing different ive NEVER noticed in using prime95 for 3+ years..

blend uses 99% cpu and all your ram.. where as before it would use only a little bit of the cpu and lots of ram..

now it's near 100% both because and i guess? they saw that with the mem controller being on the cpu they need to tax that aswell even when testing memory.. which would make memtest86 useless ?

---- when you say it used to use a lot of ram and low cpu your settings are off. your spilling over into virtual memory and that causes bottleneck problems prime 95 accesses the data in ram 100 times a second or more and uses a great ammount of bandwidth if you lower the ammount of ram you let it use youll notice it wont bottleneck thats because the ide/sata wont be interfearing.


Trying to answer a few misstated ideas after fully reading thread also check out
[url]www.mersenneforum.org[/url] there are proibily answers you are looking for in the hardware thread.

Basically, what I am looking for is a statement on the non-overclocked CPUs. Many of the Winchesters before 0441 fail it.

Do YOU think they are all faulty?

A wild guess:
As prime95 is heavily optimized (the program, not (neccessarily) George :smile: ) for the different CPUs, it could be the case that a new CPU can't be handled in a sense that there are some optimizations that work for all known so far but fail when an important thing is changed.

So it *could* be a problem with prime95 (a fixed version is probably easy to achieve - maybe once George can get a hold on a Winchester-equipped PC?), but a general problem of the Winchester CPUs is possible as well.

Let's wait for George, as he's the only one who can say for sure, I believe.

[QUOTE=IvanAndreevich]Basically, what I am looking for is a statement on the non-overclocked CPUs. Many of the Winchesters before 0441 fail it.

Do YOU think they are all faulty?[/QUOTE]

Nah it means Prime is faulty.

[QUOTE=IvanAndreevich]Basically, what I am looking for is a statement on the non-overclocked CPUs. Many of the Winchesters before 0441 fail it.

Do YOU think they are all faulty?[/QUOTE]
I think Prime95 has probably been successfully tested more thoroughly than the early Winchesters have, with regard to stress tests.

Yes, it is possible that all early Winchesters are faulty. It's not unheard-of for a major manufacturer to release a faulty CPU early in the run -- it's happened before!!

Do you remember the infamous FDIV bug in the early Intel Pentium CPUs? Intel really, truly, shipped thousands of the first Pentium CPU before users started reporting that the FDIV instruction gave incorrect results for some combinations of dividend and divisor. It turned out that there was a bit dropped in a table entry of the FDIV microcode.

So it is indeed possible for a manufacturer to ship faulty CPUs that fail only under certain very specific conditions that most users don't trigger, but that fail repeatedly in certain situations.

[QUOTE=cheesehead]Do you remember the infamous FDIV bug in the early Intel Pentium CPUs?[/QUOTE]

Interestingly, it was one of the great prime hunters, Dr. Thomas R. Nicely, who first reported this bug. A Google search on "nicely fdiv" will turn up a host of links to the story. Here it is [URL=http://www.trnicely.net/pentbug/pentbug.html]in his own words[/URL].

Thx for the link leifbk it was a very interesting read.

At that time I was working on neural network training for an applicaiton with 50+ neural networks. Each NN training took at least 4 hours on my 486DX 50 so we purchased the latest and greatest to spend up the training only to find out during the validation phase part of the NN's trained on the Pentium machine exhibited odd behavior. After nearly two weeks of tracking down the "software bug" we heard the news of the Intel bug and retrained all of the NN's on the 486 and viola, unexplained oddites disappeared. Six months later we had to retrain all the NN's to include updated information and what took up a month of computer time was completed in less than a week on a updated Pentium machine.

Re: Nicely's (and Intel's) opinion that hardly anyone would notice any effect of the error

Coworkers of mine independently discovered the FDIV bug during regression tests while porting our electronic funds transfer settlement software to a newly-acquired Pentium. In contrast to some folks' opinion that such a bug would show up only several significant digits past the decimal point, it caused an extremely obvious, instantly-recognizable error on one of our reports -- a time interval, which should always be greater than zero (an end time minus a start time), showed up [b]negative[/b] ... not just once, but several times in a report listing on-the-order-of ten thousand transactions. My coworkers tracked down the error enough to prove it was an FDIV bug in November 1994 slightly before the widespread reporting in mainstream media.

That calculation of a time interval involved the floating-point subtraction of two nearly-identical quantities -- which, of course, is wonderful for promoting the significance of any slight error way down in the mantissa of an input value -- but that's a fairly common type of FP operation, not esoteric at all. It seems to me that Nicely's and Intel's estimates of the very low probability of anyone's noticing the bug failed to give proper weight to possibilities of subtraction of nearly-identical quantities when those quantities had been the result of preceding FDIVs. (Q: Why FDIVs in time calculations? A: Converting between fractional years/days and seconds, e.g. )

Another possibility worth mentioning is cooling. If the Winchesters are packaged with low-end cpu cooling or low-end case cooling, then prime95 would be the first/only of the mentioned tests to cause serious overheating.

A thought experiment:
You have a PC lab with one identical machine for each stress test mentioned below. Set up one test on each machine. Place a large empty cardboard box over each machine and start the tests. Prime95 should produce the quickest/most dramatic results.

:furious: Cook until evenly black. :furious: For faster results, user larger boxes and cover the monitors as well. :furious:

[QUOTE=Maybeso]
A thought experiment:
You have a PC lab with one identical machine for each stress test mentioned below. Set up one test on each machine. Place a large empty cardboard box over each machine and start the tests. Prime95 should produce the quickest/most dramatic results.

:furious: Cook until evenly black.:furious:[/quote]
Hmmm ... it might be difficult to achieve even blackness on thse cardboard boxes -- wouldn't the tops tend to char before the sides? :wink: :smile: