Author: enrico carrisco
Date: 19:44:22 02/21/03
Go up one level in this thread
On February 21, 2003 at 09:55:56, Robert Hyatt wrote: >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? I am not speaking for the engineers at all. I'm simply stating that you can't support your statement that overclocking "the fastest chips available by both manufacturers" is unreliable and leads to trouble until you know the limits of that respective core. Hence, without knowing those limits we can debate this all the way up until a new core is produced. _Main point_: If I overclock a P4 3.06GHz to 3.3GHz and P4 releases the 3.2 and 3.3GHz a few months later -- do you retract your statement that my overclock could have been unreliable? There's really no way to know. There's no way to know running that chip at the posted speed is reliable either -- if you're going talking about such minute failures that are undetectable by such real world testing programs as Prime95 and others. This is beginning to become a hair-splitting contest... -elc.
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.