I agree that fsb 66 and multi 5 is clearly a bug.

This is not my case.

I noticed that bug during tests after fsb 83 ( fsb 95 & fsb 100) and thus I did not submited a higher bugged or a higher unvalidated speed close to 330-350 that I had because I do not like someone to remove my scores or accuse me for cheating.

But my result shows picture of MMX233 cpu and the cpu multi in this case is 3.5

Fsb 83 is a piece of cake on this board even for an amateur.

I will not debate / insist anymore on that. I give up!

It 's not worth trying to prove that I am not an elephant. 

Thanks for the reply anyway.

Edited March 21, 20188 yr by varachio

FWIW, I believe you.

You are a straight shooter.

Edited March 21, 20188 yr by Mr.Scott

On 22.3.2018 at 12:40 AM, Mr.Scott said:

FWIW, I believe you.

It's not about believing someone or not. I also don't think that varachios sub is bugged or cheated. It's simply violating the rules. And I can't accept it because it's unfair for everyone who followed the comp rules while he did not.

As I already mentioned, we'll clean the database from submissions with activated DMI once a CPU-Z release with the specific bug fix is out. That means that I won't do any testing here to reproduce a result. May it be bugged or not. 

I hope you all will understand that allowing sub XYZ while blocking sub ZXY will lead to a very complicated situation and in the end you still can't be sure if a sub is valid or not. That's the problem if you can't trust things because of a software bug. We faced the same situation for some benchmarks, like hwbot prime and in the end points got removed for everyone. 

I know......and understand.

 

On 19.03.2018 at 8:30 PM, Strunkenbold said:

Thanks testing this also on Ali. 

Just from reading different sources in the net it indicates that 3,5 is Max and only applies to early samples. I can not give a technical explaination but I do think it depends on the internal wiring of some pins of the CPU, thus setting a multi of 4 and up doesn't do any difference because it would need another pin which the MMX completely ignores. In the end it's just another proof that those CPUs cannot get fully unlocked and every result with high multi was CPU-Z bugged.

A bit late but nevertheless. P55 core (classic Pentium MMX) has two multiplier pins BF 1:0. Two pins give us 4 combinations and they are 2x, 2.5x, 3x, 3.5x - 133MHz (not presented in desktop CPUs), 166MHz, 200MHz and 233MHz. So anything over 3.5x on P55 is software rubbish (Pentium Pro has the same problem, BTW and maybe Klamath). But the CPU frequency should be O.K.

As for unlocked - Intel started fighting with overclocking and cut down higher multis on latter P55 and some P54C. I suppose it has been done by cutting (or not wiring) the package (plastic or ceramic) to the core. Early samples didn't have this making all multi available.

 

There is a number of things CPU-Z can be better (showing onboard cache like it did on old versions but stopped) we might want a thread for that. There's been only but maybe a separate for old hardware would be nice, sometimes it's hard to find a work-around working single as it requires different hardware...

Edited April 5, 20188 yr by Antinomy

On ‎05‎.‎04‎.‎2018 at 5:39 AM, Antinomy said:

A bit late but nevertheless. P55 core (classic Pentium MMX) has two multiplier pins BF 1:0. Two pins give us 4 combinations and they are 2x, 2.5x, 3x, 3.5x - 133MHz (not presented in desktop CPUs), 166MHz, 200MHz and 233MHz. So anything over 3.5x on P55 is software rubbish (Pentium Pro has the same problem, BTW and maybe Klamath). But the CPU frequency should be O.K.

CPU-Z 1.84 is out now for some days and I can confirm it fixes the bug showing wrong frequencies. It doesnt only affect Pentium Cores, in general all Socket 5 targeted CPUs only have 2 Pins thus anything over 3.5 is bugged.