knopflerbruce

Thanks I'm quite happy with this one. My other 3 high-end 5000 series chips are all duds...

Well, Couldn't boot 4.5 on this sample. I guess I have to trust my E2180 or an untested E2200. Best of the E2220's I've tested so far does about 4700, but i can't remember if that was just boot to OS or a bit more than that. If you can run 4.9 wp32m you've got a better chip than any one I've tested so far. Is it an E2220 at all?

Thanks:) Not using the right OS, this 2k3 is made for superpi not ucbench... will try XP later when I've gone through the rest of the 2000 chips. I can't believe I haven't found a good E2220 yet, binned through 7-8 chips already and nothing but junk:o This chip won't do more than 4450 tops...

REX + QX6850 2k3, but same issue with Maximus Extreme.

Great work! Not much left and you're top 10

Sandbaggers!!

My qx6850 ucbench submission is also bugged. Works at stock, but not OCed. MP is fine, but FSB reading is way off:p I hope Franck will go back to the old algorithm, that worked very well.

It should be allowed. If it works or not is a different question, I remember there was a technical problem in a competition a while ago - amybe that's sorted now?

1.60 sucks on my qx6850 as well, check my ucbench score:p Funny thing is it works at stock from what i remember...

Well, should be a piece of cake to show a superpi screenshot at 8 GHz+ with proper performance. That should help if there's something unbelieavable here.

Ebay, plus I got a friend who worked for AMD a long time ago:p

http://img04.taobaocdn.com/bao/uploaded/i8/T1k0lDXf4fXXbBvMo0_035312.jpg_310x310.jpg - not my chip, but same model. Retail and all.

Need to add that runs with changed advanced settings are still defined as default runs.

Since when did the mem tab become optional? AFAIk it has been mandatory since 2008 at least.

Then we have to block maybe 50% of all 3DMark scores posted on HWBot, very few run 01 in the normal run order, include cpu tests in 3dmark03 and 05 - for example. Default enough to be verified by FM, but still not 100% default. I agree that this is not an ideal situation, but the admin of the site already said this tweak is OK. Still 10 days for people to rerun if they need to.

Maybe we need to define "default settings" - what we actually mean (I think) is that settings that change the amount of calculations are not allowed. Splitting the work into 64 equal amounts instead of 2 does not change anything. Removing unneeded subtests: the same. The score is not a combined score. it picks the best result out of whatever tests you select, and then it does make very little difference if you remove the ones you have no faith in.

Did any of you guys actually rerun the benchmark? I tried it using myq7700, and I didn't get the boost in the same spot both times... rofl.

I don't know if i have the power to decide anything, but I'm thinking we allow this at least for this competition unless anything else has been decided within 45h30min from now (midnight july 5th my time:p). Simply to not ruin the competition and give people a fair chance to rebench if they want to.

I'm not writing the rules right now, I'm just participating here:) Most of the gains from the pcmark tweaks can be explained once you know how they work, right? That's not the case here - I've never seen 32 threads per core be a very efficient way of running a benchmark. What is it with this benchmark that makes it scale that way?

It's allowed if it's not "bugged", which is what you've been told.

Default settings usually means that whatever settings that changes the amount of data computed should be left unchanged. Removing unneeded tests has nothing to do with default settings for the part of the benchmark that produces the score - which is why it's perfectly fine to skip CPU tests in 03 and 05. The question here is if ucbench calculates different things when forcing 64 threads rather than the default number of threads. wprime is very easy to understand that way, there the work is split into x number of threads and all threads run simultaneously. That COULD be the case with UCBench, but it's not that clear - it just seems odd to me that you gain 20% this way, when common sense says the performance should drop.

If this is indeed bugged, the rule will most likely be that you have to select the number of threads matching the specifications of the CPU(s), or use the default selection. It's impossible to take everything into account when making a set of rules, the rules are improved when issues appear (like this). The problem is that the people who bench it (including myself) needed a LOT of time to discover this option. If we (mods) are not aware of it, then how can we add a note to the rules? And if thousands of benchmarkers needed more than a year to figure this out it's unreasonable to expect the staff to have it all sorted before a launch.

Anyway, we're investigating this... if the conclusion is that it's a bug, then these scores will be blocked. IMO the best way to get a win win situation now is to run both 2 (or 4 for quads) threads, as well as 64. Sucks that we didn't detect this earlier, but nobody notified us - and then it's not much we can do:)

If you discuss "default settings" it's relevant. You change the thread number in wprime, just like UCBench. Running wprime at 64 threads on a dual core is allowed, so why not UCBench? The REAL question is if UCBench is bugged or not at high thread count compared to core count. There is no such gain in wprime, some people run 2x core count and get a minimal boost, not 20% like in this case.

My 790FX-M2R had the same behaviour. 88 POST CODE all of a sudden. Tried so many things, 1 week CMOS clear, 6-7 different CPUs, you name it. Then I tossed it into the dead mobo box I had. Other boards were thrown into the box, hitting the DFI. Then, before I was going to throw everything out, I tested all the boards. Used a stick of RAM I thought was dead, and it booted. Worked nicely ever since, except for that +10c coldbug it's always had:D