Concerning the Haswell Memory Frequency CPU-Z Validation Bug

  • News, Articles
  • 20
  • HWBOT

Concerning the Haswell Memory Frequency CPU-Z Validation Bug

Depending on who you have in your Facebook friends list, you may or may not be aware of the Haswell memory frequency validation issue. As explained by TL at the Kingpincooling forums, there is a critical bug affecting the veracity of Haswell based memory frequency validation results. It is possible to trick CPU-Z in to believing the actual frequency is higher than the real frequency by changing the memory strap from 100:100 to 100:133 after memory training or via software. In effect, software will report the memory frequency to be 1,33x higher.

This bug was uncovered a while ago and affects both the Z87 and Z97 platform.

More Detail.

Refer to the table you can find on the left (source: TL at Kingpincooling).

There are two ‘straps’ for memory frequency on Haswell. One ‘Mode 100’, or 100:100, and one ‘Mode 133’, or 100:133. Depending on the choice of the ratio, each strap is tied to a certain memory frequency. Choosing Mode 100 with a DRAM Ratio of 1:10 results in a memory frequency of DDR3-2000. Choosing Mode 133 with the same DRAM Ratio results in a frequency of DDR3-2666.

The register that stores the information of the memory ratio mode is not locked and can thus be modified at runtime without affecting the actual memory frequency. As you already figured out, this means that any memory validation result using Mode 133 can possibly be bugged. Note that the bug requires manual intervention by the user and cannot occur at random.

The memory dividers 1:12, 1:13 and 1:14 can be used without any concern. Even though the user could still re-write the register, we know that there is no memory divider higher than DDR3-2933 on the Haswell architecture. Using 1:12 with 100:133 would result in a fictitious DDR3-3200 memory divider.

GIGABYTE’s Memory Frequency Records.

Following the discovery of this problem, several sources began questioning GIGABYTE’s recent memory frequency records. In order to resolve the issue, we visited the GIGABYTE OC Lab this morning to verify the memory frequency using a top of the line oscilloscope. We first check the frequency reporting at default settings and validated the memory dividers by checking the frequency programmed in the BIOS and the actual frequency. Once we validated the dividers, we followed HiCookie and Sofos1990 process to raise the memory frequency to over DDR3-4500.

You can find the video below.

Based on the evidence we can conclude there is no reason to doubt the memory frequency records posted by the GIGABYTE team are in fact legit. In addition, we have no reason to doubt any past memory frequency results from any vendor or overclocker.

Update on Memory Clock Validation Rules

The staff is currently discussing the implications of this bug for the memory clock validation rules at HWBOT. Certainly, for world records set by the industry the standard should evolve to 3rd party validation using an oscilloscope to verify the overclocking result (within reasonable margin). However, given the cost of this kind of high-end oscilloscope (TWD $5,000,000) we cannot expect a normal user to live up to this rule.

We will keep you updated on any rule changes.


20

Belgium Massman says:

I hope this explains the fire on Facebook last weekend. The staff is discussing intensely as I'm typing this.

Poland Xtreme Addict says:

Ban all MFR lol :D

Australia bob(nz) says:

Been a lot of drama on the topic, but not sure we should be calling this a bug though. If someone is using this it's a deliberate manipulation of the software. For me bug = random false results, not deliberately changing the result every time using the same method! I would use another word for that starting with a C

Glad to see GIgabyte cleared using the scope for proof - anyone else stepping up for validation?

United States dumo says:

Dayum...theeres my 4000+ submission :( Lol

Germany der8auer says:

bob(nz) said: Been a lot of drama on the topic, but not sure we should be calling this a bug though. If someone is using this it's a deliberate manipulation of the software. For me bug = random false results, not deliberately changing the result every time using the same method! I would use another word for that starting with a C

Glad to see GIgabyte cleared using the scope for proof - anyone else stepping up for validation?



You're not the only one thinking like that. But since these results have not been posted on HWBot.org we will not react on it. I'm personally just disappointed to be honest. They should know better.

websmile says:

Who cares for validation anyway, this is promo stuff and not the first time an issue like this occurs (still lot of people post 3:5 775 validations). It won´t make your rig faster on benching. Of course, with boints provided, hwbot will have to clear this, but I agree with Roman that this is more disappointing with people again exploiting a bug to cheat than really affecting overall ranking

Russian Federation Antinomy says:

Why not make the register WOR in the first place?

Belgium Massman says:

"Oops"

TaPaKaH says:

How many 100k€+ osciloscopes did Gigabyte bin? :D

Christian Ney says:

Antinomy said: Why not make the register WOR in the first place?


^This

websmile says:

Why not fix the 775 3:5 divider as well at same time? :D P.S. I can already see GA selling osciloscope UD series :p :D

Indonesia Lucky_n00b says:

So, until further notice, Haswell users should just submit memory validation with 1:14 Divider Mode 100 (DDR3-2800 option) then, is this OK?

United States Splave says:

gotta remove them all imo for now, It seems manufacturer participation is needed at the bios level to make this work....sad

Greece sofos1990 says:

I didn't know about this bug until Friday morning. I asked and this bug exists from last year (Z87). Why do people care for one year bug? Why noone didn't say something for a year now? :)

Christian Ney says:

not a bug Stop calling it "bug"

United States Splave says:


France marmott says:

Anyone that has already tried max memory frequency would know if their bios has the bug/hack.

It is impossible not to, and if you still try to submit the hacked score then you try to cheat.

Some motherboards are more gifted for max memory frequency than others but it doesn't becomes a walk in the park all of a sudden when you use them.

Canada Mindblowingj says:

A bit lame my board works sooo much better on the 266 divider :( Quick question: I assume only max frequency memory validation is affected ? Meaning I could submit another benchmark using the 266 divider without penalty ?

OC ME says:

Ahhh! So never use the listed "bug modes".Got it!
The Friday war ... lol

Denmark zzolio says:

Mindblowingj said: A bit lame my board works sooo much better on the 266 divider :( Quick question: I assume only max frequency memory validation is affected ? Meaning I could submit another benchmark using the 266 divider without penalty ?


you can still bench with all the dividers without problems

Please log in or register to comment.

Leave a Reply: (BBCODE allowed: [B], [QUOTE], [I], [URL], [IMG],...)