Author: Robert Hyatt
Date: 06:55:56 02/21/03
Go up one level in this thread
On February 21, 2003 at 06:47:48, enrico carrisco wrote: >On February 20, 2003 at 11:55:42, Robert Hyatt wrote: > >>On February 20, 2003 at 09:36:24, Jeremiah Penery wrote: >> >>>Prime95 is a real-world application. It does very intense mathematical >>>calculation, testing several-million-digit numbers for primality. I don't >>>believe there's another program that will detect CPU problems faster. >>> >> >>The problem is that it won't detect _any_ floating point problems. Nor problems >>with unlikely instructions such as BSF/BSR, or fiddling with O/S issues like >>cache flushing, fiddling with the memory type and range registers, and so forth. >> >>There is a _lot_ of the chip that such an application simply doesn't touch, and >>when >>you use such a test to say "it works" it is like flipping a coin. If all you do >>is use >>the same instructions, you may well have a winner. But if you use something >>that your >>test didn't exercise, who knows? >> >>I don't have time for those kinds of random problems. If you do, that's >>certainly up >>to you to choose overclocking. >> >> >>>I overclocked my CPU for a while, and it appeared to be completely stable. I >>>could run Crafty for days with no problems, and I never had a crash or bug in >>>any other application. I ran Prime95 for a while, where a calculation error was >>>soon detected. Of course, when I clocked back to the normal level, the error >>>went away. >> >>Unfortunately your testing is backward. You assumed it was good because it ran >>without "crashing". But are you _sure_ crafty never computed a bad score? Or >>hosed >>the hash signature? Or generated a bogus move? No way to know. And if prime95 >>runs with no errors, are you _sure_ all the floating point stuff works? MMX >>stuff >>works? Oddball things like bsf/bsr? >> >>That's the flaw in this... >> >> >> >> >> >> >>> >>>I was running at somewhere near the maximum rated speed for that particular >>>core, which had about zero headroom to begin with, so the errors weren't all >>>that surprising to me. Had I bought a slower chip, I could have overclocked it >>>to the speed of my current chip very safely, as the core obviously has the >>>ability to run at that speed. Overclocking becomes particularly unsafe when one >>>tries to run at a speed above the normal ability of the core. Otherwise, it's >>>not much more than what the manufacturers do by taking chips from the same >>>silicon wafer and splitting them into different CPU speed bins, as those chips >>>should be theoretically _identical_. >> >>Note that we are not talking about buying 2.0ghz xeons and overclocking to 2.4. >>We are >>talking about buying the fastest chips made and overclocking _those_. That is a >>completely >>different issue, and that is what is being done in the cases being discussed... > >How do you know what the maximum _planned_ speed of a certain core is? Until >you know that, the whole discussion is an endless loop. > >-elc. When I did TTL design years ago, I simply took the published gate delays for every circuit I used. NAND gates, NOR gates, 16-1 mux, 1-16 demux, an ALU, you name it. I added up the gate delays, plus the published tolerances, and started testing somewhere longer than that and shortened the clock to the actual number computed by the longest-path analysis. The engineers _know_ what the max speed is. I hope you don't think they lay the thing out, build it, then see how fast it will run?
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.