Author: Sune Fischer
Date: 17:18:25 07/02/03
Go up one level in this thread
On July 02, 2003 at 19:37:46, Aaron Gordon wrote: >You can test how close they are to the limit. Please read: >http://www.talkchess.com/forums/1/message.html?304354 You make it sound like you can state things with 100% certainty :) What you are doing is not exact science, it's more of an ad hoc, "oh seems to be working fine" experiment, IMO. This may be sufficient in many cases, I can't say it ever worked for me 100% though. >>You don't know how close they are to the limit. >>When you clock them that high they burn watts like crazy, and if the average >>user doesn't have enough cooling... > >I test these processors with average cooling, and then slow the ran RPMs down to >further heat up the processor to make sure everything is fine. I then clock the >chip down AND increase the voltage a bit. Read about it above, I explain most >everything and include formulas so you can do the calculations yourself. Upping vcore can also lead to instability, burns more watt for instance. >I use to do a little bit of work with AMD, during this time I talked to a few >people (also AMD employees) that knew about what was going on in the fabs. Also >a lot of it is common sense. Try taking one of the original 1700+ chips, some >of the very first ones released. Now, compare one of those to the 1700+ >handpicked chips I have. You'll get about 1GHz more out of one of my chips. :) >This is due to AMD making the *best* cores 24/7. It is probably true that by design they are identical, ie. I wouldn't be surprized if all XP's are really born MP's. But the difference is (or used to be) that the XP's are not tested and guaranteed to work as MP's. So you can by XP's and get lucky that they work also as MP's, or you used to before they did the wirering. Or maybe some chip which was designated to become an MP failed the test and ended as an XP chip instead. >Also something interesting I found out (and suspected this before finding out >from someone at AMD) is that all of the chips are blanks. Looking at an Athlon >and knowing what the bridges do you can conclude the chips come blank, then are >cut by lasers to whatever AMD wants. This means every single Athlon XP was an >Athlon MP before the last L5 laser bridge was cut. This was verified by an AMD >employee working in the Dresden fab after I asked him about it. Yes they are blanks, only after testing them can they be cut. :) >Most people assume they go through some elaborate testing, verification, etc. >They just quickly verify if the core 'works', and knowing the chips will do >~2.4GHz they mark them whatever they want. They do this after they send the >individual cores to Malaysia though. This is where they put the silicon on the >OPGAs and then cut the bridges to whatever they need, be it an Athlon MP 2800+ >or an Athlon XP 1700+. They do have different lines for the different cache size >chips, though. Obviosly :) > >Could be windows or program related, or maybe he's just overclocking "too much". >Make sure he runs two copies of BurnK7, so both cpus are being used. Also if he >passes an overnight run w/ two BurnK7's have him fire up two copies of Prime95 >as well (not at the same time as BurnK7 though). > >He could have fault ram as well. I've seen this MANY times. People blame the >cpu, board, etc. Have him also test his ram with memtest86 @ www.memtest86.com It could be any number of things, the problem is that it is _almost_ stable, and no program has ever succeded in crashing it reproducably. He's run the SiSoft package and loads of other stuff of course. I fear maybe there are other chips like that, that will pass the average stress test and only show itself under rare conditions, or maybe the error is always there but that part of memory usually doesn't cause crashes, or whatever. Crashing is really major instability, it's bound to be harder to reproduce if it is only slightly unstable. -S.
This page took 0 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.