Antinomy

BTTU

There were several cases like that, I remember in AM2 era or maybe it was 939 when a lower multi CPU was installed after a higher multi and booted at it. I consider this a CPU bug pretty mich like the unlocked i5 3570 which was the last mention of such a "miracle". I don't think these are repeatable. But sometimes worth checking (unlocking multi on mobile Haswell with old CPU microcode).

Nice clarification, @GeorgeStorm! I thought general sense was enough to understand that each requirement has been added for a reason and to understand those reasons. Why was CPU-Z memory tabs added, GPU-Z, 3DMark windows and certain details on them. And why was Cinebench enforced (I got hit by this one though didn't know the cheat before obviously). But maybe since there are people that don't understand why certain windows are required and what info on them is essential, maybe it's worth specifying. @daimons, I've got a whole lot of such screenshots: http://hwbot.org/submission/3834865_ (not full memory page) http://hwbot.org/submission/3831473_ (not full CPU page) http://hwbot.org/submission/3831472_ (not full motherboard page) And a whole lot more, usually I don't put the full memory page on almost all my subs. Will you try to report them all?

Finally after all these years!

@max1024, now we're talking! Nice point and I agree with this. Unreal 🤣

Nice catch, I thought I fixed both but somehow 650T fix didn't apply from the first try. Thanks for reporting, fixed now.

Indeed, PII X4 840T is a Zosma core. But Zosma is a Thuban with 2 cores disabled. I think stage mods wanted to limit hexa-cores so they should clarify unlocked Zosma in the limits. So right now W9 are technically right and maybe stage limitations should be updated and clarified. Nice loophole @cbjaust, don't worry this is a minor mistake in DB. If you find mistakes, just make a ticket in Support forum. Fixed both. So the categories are OK, now it's up to stage mods.

These are details that can be sorted out later. First is to come to an agreement. The problem is we can't prevent Pentium 200 posted in Pentium 166, same for socket A and so on. At least we could ensure that a result in a rare category was made by someone who actually owns such a hardware. And easier to sort things out later if category was selected wrong (or detected by software wrong) or was split/combined. ATM I need community's understanding.

@yosarianilives, please stop offtoping this thread with other benchmark discussions and whatever. This thread is about CPU-Z freq. bug only. Or I'll have to ask mods to clean it. O.K. for those who didn't read the f**king datasheets (кому было лень учить матчасть): There's no way to detect 100% sure multiplier on these CPUs so there never was an accurate FSB detection. First I was confused when I was it added in new CPU-Z because these CPUs don't have FS (frequency select) registers that represent corresponding FS pins that are set. Franck tried to guess the multi based on standard clocks (read - default FSB and clock speeds). That's were it got wrong. I wasn't aware that CPU-Z could show wrong clocks because I used the older versions so they don't show stupid multipliers. CPU-Z tries to guess a combination of standard multi&FSB from a table and then simply multiplies them. So it doesn't take CPU frequency that can be measured via TSC counter and then guess multi and FSB but the other way around - it tries to guess FSB and multi and multiplies then to show the speed. Exactly the same way you see incorrect CPU speed on your POST screen during overclocking (they are taken from a standard FSB*multi table too on most boards). So there's no way for software to detect multiplier and hence bus speed on these CPUs (Winchip C6, Pentium/MMX, AMD K5). There are some complicated mechanism to guess the multiplier right but it will require time and effort to check how reliable it is not to mention efforts to implement it. In fact, lack of multiplier detection is not a big issue. Since you all are here, I'd like to propose another verification issue - requirement of CPU fotos for S5/7/8/A/370(Cyrix), Slot 1/A. Any arguments against it?

Just my $.02 - language barrier can be a bitch for some of the members. Sometimes it makes things easier to explain and understand. It's up to forum mods to clean it up though. If any of our exUSSR guys want to clear things out in Russian, feel free to PM me or create a topic on Russian forums. I'm not about ranting but can give you the technical details you think this thread is lack of.

I'd like to remind you what HWBot was initially about - it's a hardware performance database. Think about it, reread it and think again. It's only three words, you can handle it, I'm sure. Points, rankings, leagues, teams - it's all secondary. It's simply a gamification made for fun. Fun is another thing most forget in their long discussions. So the main purpose is to keep the DB as accurate as possible, not about your points. @max1024it's NOT about crystal oscillator deviation you are talking about AT ALL. You simply don't understand the bug then. Xtal deviation affects frequency and will be seen in every realtime frequency utility. The topic is about CPU-Z bug only. If you didn't understand my two little quotes, feel free to ask for details. It's not rocket science. @Gumanoid, looks like you don't get the situation. The results were blocked not because everyone is a cheater but because we can't be sure they are real. How dare you mention Carl and talk about rules applied to old results. I'll give all of you a nice example - a long time ago there was a category called Celeron 350MHz (Covington). You'll never find such a CPU because it doesn't exist. I've found out that CPU-Z couldn't tell a Pentium 2 Deschutes with L2 cache disabled in BIOS from a Celeron Covington (they share the same core) which doesn't have cache at all. How do you think, how many people commented that their scores were bugged, how many reported to CPU-Z? Don't try to "they might not know" - you can't disable L2 cache in BIOS by accident. And Pentium cartridge and PCB looks whole different way from Celeron. So Carl deleted the whole category along with results. And I've reported to CPU-Z and got this issue fixed. And nobody got banned. Some of them were teammates of those who participated in this topic. Would you really continue with this "rules don't apply backwards" and let fake category with false results stay? Important to not - results weren't painted, neither they were fake in general way. But they were erroneous in terms of hardware performance database. That's how it was done and how Turrican reacted in such a case. Back to this issue - it should be sorted out. Maybe we could make exceptions for some cases like non-overclockable boards if a result seems normal and doesn't cross the bug mechanism. Not for me to decide though, it's up to results mods.

You have no idea how many water condensates with 95-98% humidity (which stays all the summer) and with +10-12 degrees from the tap. ZFeSS had to reinstall cooling every hour during previous OSBIS comp 😉 In America you chill water. In Soviet Russia, water chills you

added: http://hwbot.org/hardware/motherboard/x399_sli_plus_ms_7b09/

http://hwbot.org/hardware/motherboard/z370_aorus_ultra_gaming_20/

They are Chinese. Try Ebay, they've been there some time ago. You have to be well experienced in hardware to make use of them. They require certain knowledge and sometimes mods.