Ram performance drop X79 @ 2400 divider

[xpower]

never wanted to start a new thread but just for sharing this bad experience with intel x79. i know the workaround to this problem can be resolved by using strap or even straight rising the higher or less ram divider. but @ default 100 bclk and 2400 ram dividers give bad ram performance in latest Aida and or other memory benchmark. i have yet to confirm this with other x79 users the same behavior.

[NEOAethyr]

I can confirm this with the r4be board, it's a really tough bug to get around too.
I wrote alot of notes on it but haven't finished figuring out what exact bclk's it effects.

Oui I thought they were sorted..., I guess not, and I thought I had more notes sorted (I have more but they seem irrelevant).

Going from bad to good bandwith:

1. Load cmos profile or do a power up from complete shutdown, bandwith is bad beginning at this point.

Restart
Set cpu multi to 38, restart
Set cpu multi to 40 + set ram div lower at the same time
Restart
Set ram div higher
Restart
Done, bandwith is back to normal

bug happens on complete shutdown
bug also happens on unstable shutdown when pressing reset button

It effects 100mhz bclk for sure, my best way of getting around it is to use 114mhz bclk and use the methods above to get around it.
I managed to get around it ONCE on 100mhz bclk a while back.

Are you saying it affects the r4 gene board as well?

[NKrader]

serious question,
likely only noticeable in sythetic benchmarks?

[NEOAethyr]

serious question,
likely only noticeable in sythetic benchmarks?

Well if you're truly being sincere about it, I don't know.
All I know is that you get half the mem bandwith with this bug.
What exact apps it affects other then aida64 I don't know.

But I will put this bluntly because I think you're gonna ask this next.
It's NOT a software prob!
It's a problem with the motherboard.
Not a hardware defect though, it's a bios issue.

Would you be happy with half your mem bandwith?

[PCZ]

It is not a hardware defect.
Plane and simple the sub timings changed in the BIOS.
Older BIOS versions did not have this slowdown above 2133MHZ.

Why ASUS changed the default sub timings I'm not sure but have my suspicions.
They could be following Intel recommendations, or more likely are using slack timings to allow higher memory clocks.
The performance wont be there but average joe won't notice.

If you want good memory performance at 2133 and higher then you have to change the sub timings.

On the old BIOS versions for my P9X79 pro and Sabertooth the memory performance is good at all clock speeds.
The nanny sub timing changes came fairly recently.

[NKrader]

Well if you're truly being sincere about it, I don't know.
All I know is that you get half the mem bandwith with this bug.
What exact apps it affects other then aida64 I don't know.

But I will put this bluntly because I think you're gonna ask this next.
It's NOT a software prob!
It's a problem with the motherboard.
Not a hardware defect though, it's a bios issue.

Would you be happy with half your mem bandwith?

what kind of bandwidth should I be seeing on quadchannel 2400?

[NEOAethyr]

@ PCZ
Interesting take on it, but I have disagree or the timings you speak of aren't accessible to me rom the bios or memtweakit.
Take a look at my screens below.

@ NKrader
Take a look at my screenshot below .
(Well they are taken at the 2400mhz div anyways.., you'll get the idea, and ok it's not 50% lol, but still )

Oui the image upload still doesn't work here.
Gimme a seccy to find a site to upload to.

Bad:


Good:


I made these pics on feb 21'st, so it's been a while.
Hopefully I up'ed the right ones...
Hmm why 110mhz blk, I've been running stock 100mhz bclk for some time now I must of forget, I swore I ran it at 114, ohwell.
Anyways there's there's the proof of the bandwith bug and that they are running at the exact same timings as a good bootup vs a bad bootup.

[NKrader]

here is me

[xpower]

yes Gene also effected with this with latest BIOS. did lots of tweakings vtt, vccsa, vcore manual,offset etc even tweak second third timmings but no. its not sub timmings or volts.

@NKrader "as you can see in memory write performance dropped with 36:3 divider

[NEOAethyr]

Ok guys, I wanted to show NKrader a 100mhz bclk run of the good and bad, and found my board didn't wanna power off when changing cpu multi's like it normally does except at high bclks.
So I could not enable the fix or enable the bug either (I was stuck with the bug...).

But I figured out a work around for when the board doesn't power off on it's own.

Your cpu multi may differ, but the steps will be the same.
1. Set cpu multi from 44 to 42.
2. Power off.
3. Set ram div to 2133 and cpu multi back to 44.
4. Power off.
5. Set ram div back to 2400.
Done .

The 1st power off may not be needed I'm not sure yet, but the 2nd is most likely needed.
Follow those steps and check your aida64 write bandwith, it should reach in the 60k's instead of being perma stuck in the 40k's.

Your cpu multi may differ, that's what I run with at stock volts.

Now as soon as I do a full power off the bug will appear again that I'm sure of.
A reset is fine though, the bug won't reappear.

@xpower
I spent alot of time trying to figure it out too, voltages and timings don't make any difference.
Actually there isn't a single setting the bios that will fix it, I tried all the funky settings too, full init stuff and that whatever they are called, not single one fixed it.
The only fix is to initialize it right with the cpu and ram multipliers.
Getting the right combo is key.
Try my steps above and see if you can get the bandwith back .


PCZ is saying that's there's yet another 2 board affected maybe.
So far it seems the gene and black edition are affected for sure.
Looks as if NKrader even has the bug and probably didn't realize it , then again cmd rate 2t might not help lol, but still I think it looks like the bug on that screen.


Edit:
Oh forgot to post my screens, just took these .

Bad:


Good:


I'm starting to think this affects every asus x79 board...

[plane501]

I'm starting to think this affects every asus x79 board...

R4F confirmed the problem with bios 4804、4802

[Shiranui Gen-An]

Curious. Is this behavior seen if one uses the preset DRAM profiles?

[NKrader]

Curious. Is this behavior seen if one uses the preset DRAM profiles?

I think mine is set to xmp profile actually

[NEOAethyr]

I don't use the profiles but I have in the past and they didn't help.

I 1st thought it was vccsa or vtt.

Then I thought it was dram rtl's and iol's, because well, long story kinda...
Those sets of timings are baised off an offset, which is a royal pain in butt.
You set say -2, restart and end up getting results you don't expect.
They just don't work right to put it simply.
Auto works but they can change on there own, and they can change baised on the order you put your sticks in (using the same slots).
Because of that I thought these timings were the main prob, and because when I asked for help on this on the overclock.net and got screens of people's good bandwith at around 2600mhz these timings differed greatly from mine.
I manage to get it to behave a little by switching one of my sticks around, but setting it manually is still like the lottery :\.
It does some really goofy stuff when you try to manually offset them, very tricky stuff.
I spent a few days working on them, I can kinda get them todo what I tell them todo lol.
Anyways.. I had managed to get it to match another dudes timings and it didn't fix the bandwith prob.

Another was the latency boundry setting and rampage tweak mode, didn't help.
Dram clk period didn't help.

Other settings I tried were mch recheck, mch fast reboot, training options..., clock gen full reset.
Even tried disabling the epu power savings and spread spectrums (which I normally use).
Tried every single voltage, couple diff ram profiles, swapping my sticks around...
For a while there I was worried that I would need to rma my ram .
In the end it's just some goofy bug with the way the cpu and ram div initializes.
(Oh and it affected both my cpu's, 1st got fried by accident)

One of the 1st things I started doing was complain about the 2400mhz ram div being slower then 2133...
And then at one time, I managed to get my bandwith back, and then I changed my cpu multi and I lost my bandwith (my board usually but not always powers off during a multi change).
There were times were I wanted to take screens of the 2 diff ram divs and saw that both had the bandwith issue.
Somehow I figured out if I change both at the same time in the right combo I get the bandwith back :\.

It's a really annoying bug.
Once you fix it, sometime you're gonna power your machine off and it's gonna be right back.

Listen to this, I saved the good bandwith runs in my cmos profiles, several times before I figured it out.
Say you have bad bandwith, load a cmos profile that had the good bandwith and you will not fix the bug ^^, that in it's self is really crazy.
Then again the bios profile doesn't save the boot logo setting for example...
But it's gotta be something todo with the bios'es cold boot code.
Heck it could even effect all x79 bios'es I don't know, what I'm saying is maybe it's even an ami bug.
But it's probably asus.

I've got a list of a dozen (at least) bios bugs for this board of mine, I was gonna try to show them to RGone but I got busy with android 4.4.2 and linux instead.
The one we're talking about though is the one I'm most concerned about, other then the darned boot order and boot menu bugs.

[NKrader]

I don't use the profiles but I have in the past and they didn't help.

I 1st thought it was vccsa or vtt.

Then I thought it was dram rtl's and iol's, because well, long story kinda...
Those sets of timings are baised off an offset, which is a royal pain in butt.
You set say -2, restart and end up getting results you don't expect.
They just don't work right to put it simply.
Auto works but they can change on there own, and they can change baised on the order you put your sticks in (using the same slots).
Because of that I thought these timings were the main prob, and because when I asked for help on this on the overclock.net and got screens of people's good bandwith at around 2600mhz these timings differed greatly from mine.
I manage to get it to behave a little by switching one of my sticks around, but setting it manually is still like the lottery :\.
It does some really goofy stuff when you try to manually offset them, very tricky stuff.
I spent a few days working on them, I can kinda get them todo what I tell them todo lol.
Anyways.. I had managed to get it to match another dudes timings and it didn't fix the bandwith prob.

Another was the latency boundry setting and rampage tweak mode, didn't help.
Dram clk period didn't help.

Other settings I tried were mch recheck, mch fast reboot, training options..., clock gen full reset.
Even tried disabling the epu power savings and spread spectrums (which I normally use).
Tried every single voltage, couple diff ram profiles, swapping my sticks around...
For a while there I was worried that I would need to rma my ram .
In the end it's just some goofy bug with the way the cpu and ram div initializes.
(Oh and it affected both my cpu's, 1st got fried by accident)

One of the 1st things I started doing was complain about the 2400mhz ram div being slower then 2133...
And then at one time, I managed to get my bandwith back, and then I changed my cpu multi and I lost my bandwith (my board usually but not always powers off during a multi change).
There were times were I wanted to take screens of the 2 diff ram divs and saw that both had the bandwith issue.
Somehow I figured out if I change both at the same time in the right combo I get the bandwith back :\.

It's a really annoying bug.
Once you fix it, sometime you're gonna power your machine off and it's gonna be right back.

Listen to this, I saved the good bandwith runs in my cmos profiles, several times before I figured it out.
Say you have bad bandwith, load a cmos profile that had the good bandwith and you will not fix the bug ^^, that in it's self is really crazy.
Then again the bios profile doesn't save the boot logo setting for example...
But it's gotta be something todo with the bios'es cold boot code.
Heck it could even effect all x79 bios'es I don't know, what I'm saying is maybe it's even an ami bug.
But it's probably asus.

I've got a list of a dozen (at least) bios bugs for this board of mine, I was gonna try to show them to RGone but I got busy with android 4.4.2 and linux instead.
The one we're talking about though is the one I'm most concerned about, other then the darned boot order and boot menu bugs.

someone should email asus

[plane501]

someone should email asus

GIGA and MSI have the same problem

[NEOAethyr]

I sent a pm to rgone to check this thread, but he hasn't been on the forum since 2013 so not sure if it will help.
Tried to send praz a pm but but got a pm box is full error.

I'm not signed up at asus'es support forum but I'll try to sign up and pm them there.

Edit:
Made a thread on there forums hopefully we can get some attention to this.
http://rog.asus.com/forum/showthread...all-x79-boards

[xpower]

does seems like x79 chipset problem. and not the boards manufacturers.

[learners permit]

I remember a few years back a similar problem with another board RDX200 I think. Anyhow it was an overlapping Tref setting being selected improperly by the bios. Would one of the affected please use memtweakit to see if it's the case. Perhaps another value of 7936 can be selected for dram refresh interval and retest.

[NEOAethyr]

@ learners permit
If you take a look at my 1st set of screenshots you'll see I got tREF set to exactly 7936.
It's not tweaked, pretty much stock.

I have changed it in the past, diff profiles and auto detections at diff settings changes it slightly and it's made made no difference :\.
Though I appreciate the suggestion.

[xpower]

this only affecting Ivy Bridge-E with x79 and does'nt affect sandy Bridge-E. i dont know ASUS is aware of this.

Even all x79 platform with Ivy Bridge-E are affected.

[NEOAethyr]

I'de like to see screens of another brand of motherboard, that's what I'de like to see.
I don't doubt it does affect them but I'de still like to see it.

[xpower]

@ NEO any findings?
i think we are done here. no response from ASUS of any sort. have to stay with that bug i thing.

[zoomee]

same problem here
4x4Gb 1866 C9 = 52K read, 52K write
4x4Gb 2400 C10 = 58K read, 42K write!



Look at that abysmal write speed on the 2400 ram

[NEOAethyr]

@ NEO any findings?
i think we are done here. no response from ASUS of any sort. have to stay with that bug i thing.

Yeah I don't know, the thread on asus is still alive, it gets bumped once in a while.
I let it go for a while and if it's not in the front page of the rampage section I bump it, but lately others have been posting in it .

I really don't know what else I can say though, I did find however that the bug is a bigger prob then initially thought, as it affects the cpu multiplier too.
I guess we need some peeps at other forums to post about it, more people need to be aware of it so it doesn't go unnoticed to the majority.
And if nothing happens, well then it's time to start having reviewers and tech news sites post it on the front pages to get this thing fixed.
But we gotta give it time.

I do think it's intel's prob, but we'll verification of that, need to see other board brands affected.

As for any feedback I've received, notta, ziltch, absolutely no word at all from a rep or mod about this.
I can see praz is aware of it, seems they are reluctant to reply on it, which I can understand to a point but d2mn.

As for sticking with the bug forever, nah screw that.
I'll sell my cpu and go with the 3930k instead, or perhaps just sell whole rig and go with a 4790k or something (wtf...).