Dear Fingolfen:
How people refuse to look at history.
Re: "That is the most ridiculous piece of FUD I think I've ever seen you post... and it's totally without basis...
If you actually READ the article you cited, the author indicated:
"I don't know if the fault lies with DirectX 8, Windows ME or the 12.41 Detonator drivers - but my old favorite benchmarks won't run. I don't believe the problem is with the motherboard or processor as I was able to run those same benchmarks on several i850 based motherboards with a 1.5GHz P4..."
Looks like a software issue."
Wrong! Remember Tom's hardware and the P3-1.13 Linux kernel compilation bug. A 1GHz P3 compiled it just fine and the P3-1.13 failed. Everyone blamed Tom, yet it was repeated by another site. The problem was found with just the new speed grade failing due to a speedpath issue. I told you in my post that this could be, repeat could be, (not is) something similar. He stated that the benchmarks ran with multiple i850 motherboards with a 1.5GHz P4. So the old bin works and the new bin fails.
The OpenGL problem was not that the benchmark fails to run but, that it runs slower than it should. Thus, OpenGL is not one of the benches that failed to run. There is a huge difference between a program that runs slowly and one that doesn't run at all. Thus, all you are saying is that you hope that it can be traced to some timing loop ala AMD K6-2/400 that caused MS-Windows to have an overflow error (the same thing happened to higher clocked P2s). That was traced to the software being poorly written.
If a sequence of instructions can cause the program to die or worse lock up the system, this could be another place that Intel failed to test the CPU properly which depends on what the benchmarks that failed are. If one is a benchmark that was run a lot, Intel should have tested it. If they are new or infrequently used, Intel could be forgiven not testing it but, they should retest and if the problem affects a significant percentage, say more than 2 or 3%, the processor should be pulled, then what is causing the error should be fixed and if that requires a new stepping, they should make a new one, add the benches that failed to the verification suite and re-release the CPU. Alternatively, they could simply wait for Northwood checking that it does not fail the benches.
Complaining that something is FUD is how Intel got into trouble both with the FDIV problem and the P3-1.13 problem. Sticking one's head into the sand doesn't fix the problem. AMD did not stick its head into the sand wrt the JPEG problem. They found out what was wrong, added tests to the verification suite to remove those CPUs that exhibit the problem and offer to replace any CPU found with the problem. Just like they (or Intel) should do in those cases.
I would like to know which benchmarks failed and if they could be verified using another MB and/or CPU. It could be a sample CPU slipping through a crack in Intel's verification suite or it could be a larger problem. I do not know which at this point. All I did was give notice to the possible problem.
Typical response, shoot the messenger when not to your liking.
Pete |
