havli

Yes, sure you are. Killing HW is not exactly proof of skill, is it? But i guess it is understandable considering you started overclocking just a year ago

@Mr.Scott That is very nice offer and I really appreciate it. For now I'll stay in my team. But if they won't change their attitude to team competitions for the next season, then the chance to join W9 is very tempting (if the offer still stands by then). @_mat_ Well, then show me another benchmarks that gain performance from this... besides GPUPI.

Cheapest? No, not for me anyway... that would be s478 or 754. Maybe some people don't have problem doing hardmods on $600 GPU, but I do. Simple look on my paycheck is discouraging enough. Also I don't like killing HW in the process of overclocking - I have thousands of scores here on Bot... and yet I can easily count components that died on my fingers. $800 NUC or dual Titan is no concern to me, because I don't have that kind of HW and never will. Also I don't really care about TC standings at all - one-man-team can never reach decent position in competition like this. Sure and then desolder the old chip and put new one in... doable of course. But not bricking the original one is far more time/money effective.

Well, it is simple evaluation of risks and benefits. Bios flashing is far more risky than OC. And since money doesn't exactly grow on trees (at least not here ) then it is better to get the most of it by focusing on the 20 other benchmarks that doesn't require such modifications.

No, but it is not needed for anything but GPUPI... so waste of time in my book. Also the risk of bricking the MB is always there if something goes wrong.

Or the other possibility - skip the FM1 stage completely... because it is pointless to run it at normal conditions and many people won't bother flashing bios to get this tweak working.

I also saw this error from time to time on older platforms, but it seemed to be random and eventually x265 started properly. When the error message shows up, there should be file named hardware.txt in the x265 working folder if you don't dismiss the error (the file is deleted automatically after succesful detection or benchmark exit). Please upload it here and I'll take a look. Btw - 64-bit windows should be faster for x265. XP is good for 32-bit only CPUs... as far as x265 is concerned.

I agree, Strunkenbold is doing a great job to keep the bot running. Sometimes when problem like this CPU-Z situation shows up... action simply must be taken. And when we don't know if the scores are false or real with those certain CPU-Z versions, then removing all scores possibly affected is the only way to keep the DB in good state. Of course it is some amount of time and effort wasted for those people affected by this. But this isn't really anything new - several benchmarks were removed completely in the past (for example UCBench and others which I don't even remember anymore). Other had points removed (PCM05, Hwbot Prime). I alone lost hundreds points by this... and I'm still here. Cleaning the bugged results from the DB is a good thing and everyone shoud understand it.

If the scores are bugged, I don't see another way.

Did someone try to measure power consumption during these slow / fast runs? It could give some hint - if the extra work is being done, then the CPU also should draw more power.

This is why I picked 45 vs 65nm Core2, these differ only in SSSE3 / SSE 4.1 (we can disregard extra cache here). There must be some use of SSE 4.1, otherwise 4.6 GHz Conroe would always beat 4.1 GHz Wolfdale.

Well, in that case how do you explain huge performance advantage of 45nm Core2 (SSE 4.1) over 65nm Core2 (SSSE3) ? For example http://hwbot.org/submission/3678638_havli_gpupi_for_cpu___100m_core_2_duo_e8300_1min_53sec_951ms and http://hwbot.org/submission/3408835_kintaro_gpupi_for_cpu___100m_core_2_duo_e6750_2min_16sec_234ms/ Or AMD 15h or 16h (AVX, SSE 4.2) much faster than K10 (SSE3)? in GPUPI K10 is a lot slower, while in older benchmarks - Cinebench for instance it is the other way around. http://hwbot.org/submission/3691480_havli_gpupi_for_cpu___100m_a10_7800_1min_8sec_764ms and http://hwbot.org/submission/3554886_noms_gpupi_for_cpu___100m_phenom_ii_x4_965_be_1min_28sec_609ms

All available evidence speaks against some magic OCL performance boost with this specific agesa. All other K10 CPUs performs more or less the same. Llano with all boards / bios versions except this one specific combination performs the same. If there was such performance gain on Llano / even for the price of instability/ ,then it would be known in public. There is no such change in Llano architecture that would allow such performance boost when compared to all other K10. From the other GPUPI results it seems AMD OCL driver benefits greatly from SSE 4.1... and to some extent even from SSSE3. This is the reason K10 is slow in this benchmark compared to Core2, Nehalem or even 15h based processors. K10 lacks these instructions. I'm sorry but this really sounds like a bug - either in OCL driver or the benchmark itself or maybe something else entirely. It is not a random thing, as it can be reproduced... after all not so long ago there was a similar problem with GPUPI on dual socket 1366 machines which also seemed to be much faster then common sense would suggest... and as it turned out, it was a bug.

Yes, I am... because they are the same. Cache and memory doesn't matter for GPUPI and those other improvements are more or less paper dragons with very small performance impact. And btw one of my links is Phenom II.... Different agesa can be faster... but single digit percents at most, not twice as fast. And one more thing - CPU performance of GPUPI 2.x to 3.2 is very similar, as long as you are comparing 64 bit versions.

AGESA is part of the BIOS...

Obviously, this is a bug of some kind. It is not possible to have one board with specific BIOS version twice as fast compared to other boards and/or BIOS versions. Also Llano simply must be in line with other K10 quad cores running on similar clock. For example http://hwbot.org/submission/3314113_havli_gpupi_for_cpu___100m_phenom_x4_9650_2min_11sec_369ms or http://hwbot.org/submission/3699925_havli_gpupi_for_cpu___100m_opteron_8380_2min_12sec_595ms

It was clearly stated all TC2018 scores must have the taskbar visible.

Yeah, it isn't so hard to figure out the best HW for each stage. Too bad our team doesn't have the other two people who would also own it.

Stage 2 - Wolfdale-3M means C2D E7xxx series only, or something else too? Like Pentium E5xxx, which are also using this exact die but with only 2MB of cache active. Stage 9 (and also others which are done the same way) - "single server CPU allowed" .... means only Xeon / Opteron is allowed, or C2D / Phenom / etc can be used as well?

Auto-hiding taskbar is ok or not? I'm using it for all screenshots... for example http://hwbot.org/submission/3796340_

Great score! And btw - I don't see a problem with using older versions of CPU-Z and GPU-Z as long as they show the correct info.

Yeah, 3.2 is slower on Fermi... in fact it is even worse for me. For example I can't get anywhere near this score anymore http://hwbot.org/submission/3301090_havli_gpupi___1b_geforce_gtx_465_1min_5sec_319ms/

SLI can be enabled using one of the SLI hacks - for example https://www.techpowerup.com/forums/threads/sli-with-different-cards.158907/ The problem is when the chipset or CPU (as the PCI-E controller is built in there) is newer than GPU drivers... in that case SLI isn't suported (I think). The mentioned hack probably fools the driver to think it runs on X58 or something similar... and therefore SLI will work, even in XP. http://hwbot.org/submission/3502846_havli_3dmark06_2x_geforce_8800_gtx_27622_marks

The best solution would be to simply add an option to users profile - just a simple checkbox woud be enough. Either show the HW library as it is now or ignore VGA brand and merge HW categories to one of each type. Going through 50 results and trying to find the one that is marked MSI realy isn't very effective.

It is simple, just rebench the 6.9GHz CPU and done. Those who want to stay on top must rebench stuff regularly anyway. For example in 3D with every new 115x platform launch rebench of all 3dmarks up to 06... and new HEDT = rebench of Vantage and later.