Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Intel Corporation (INTC) -- Ignore unavailable to you. Want to Upgrade?

To: fingolfen who wrote (142215)	8/27/2001 2:20:27 PM
From: Dan3	Read Replies (1) \| Respond to of 186894

Re: and it's totally without basis... You hope.

To: fingolfen who wrote (142215)	8/27/2001 3:07:16 PM
From: muzosi	Read Replies (2) \| Respond to of 186894

if a newly released chip fails to run with an existing set of software, is it a software problem ? How does this issue compare to 1.13 GHz P3 & linux compiles? Were gcc or linux kernel the problem in that case ?

To: fingolfen who wrote (142215)	8/27/2001 3:33:47 PM
From: wanna_bmw	Read Replies (1) \| Respond to of 186894

Fingolfen, Re: "Looks like a software issue" The author doesn't mention which benchmark he is talking about, but it very well could be Viewperf, the OpenGL benchmark. Tech Report experienced an issue with this benchmark that only affected the 2.0GHz Pentium 4 with the 12.41 nVidia drivers. After discussing the failure with nVidia and Intel, they found that the driver was at fault, and the 12.61 driver fixes the problem. It could be related. tech-report.com "In the Awadvs, DX, and Light tests, the 2GHz P4 system shows some performance anomalies, turning in much lower scores than one would expect. I checked and double-checked this one. Vsync was disabled, the screen resolution and bit depth were set right, the proper drivers and patches were installed, the AGP aperture size was the same (256MB) as the other systems—everything seemed right. We checked with Intel, who in turn checked with NVIDIA. NVIDIA confirmed there is an issue with the 2GHz Pentium 4 and the current drivers. It apparently relates specifically to high graphics bandwidth benchmarks, and like us, they've only seen the problem in viewperf. Newer (currently unreleased) drivers from NVIDIA, labeled version 14.61, resolved the problem for us. As you can see, the red bar on the graph (which represents results at 2GHz with the 14.61 drivers) shows the P4 2GHz performing more line with expectations." wanna_bmw

To: fingolfen who wrote (142215)	8/27/2001 6:47:30 PM
From: pgerassi	Read Replies (1) \| Respond to of 186894

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