ASUS AMD Beta BIOS Releases

[Leeghoofd]

Coz everest is ... ( fill in on the dotted line) There's no FSB on AMD, HT clocks only. Disable the Turbo and see what happens then (I never use that function)

[NEOAethyr]

You were right.
Turbo mode was the prob with my fsb flutuation.
Now it says 275.9mhz all the time.
My ht and cpu clocks still fluctuates, but only by a min amount.

What the heck...
Must be everest.

Shame that aida64 is pretty much the exact same thing but with less stuff :\.
Less on the sensor page anyways.

I love the optional temp sensors on the board, I got them all in use (baught some sensors on ebay when I 1st got the board).
That's what sucks though, only everest and asus's program will show all of the sensor stuff.

I'll brb, I wanna post my one of my settings...
Edit:

Under chipset settings, dram config I think.
The dram channel interlacing setting, instead of auto try the value "Address Bits 12".
It was the fastest value for me.
You might take a small hit in stability with it though.

[wez]

That's what sucks though, only everest and asus's program will show all of the sensor stuff.

Tried HWMonitor?

[NEOAethyr]

@mav2000
What cpu are you using ???
That's the only reason I can think of...

@wez
Yeah HWMonitor pro is what I use most of the time.
I'm using v1.10 which was the latest the other day...

The voltage level's aren't quite right, especially the 12v.
And the rest of the voltages are just useless.
Fan rpm speeds don't work in it either.
And the optional temp sensors are missing from it.

I gotta use firefox to upload a screenshot to show you..., brb :\
Ok, uped a screenshot showing you the diff between the 2.
I'm gonna install the asus probe it software and show you guys why I can't use it.

Oh btw, I don't have any fans hooked to the bopard that's why everest doesn't show them.
When I do everest works in that respect but hwmonitor doesn't.

Edit:
This is what the asus program does on my system.
It says the bios, cpu, vga, etc etc fails.
Something to do with the performance counters or wmi in windows.

And if it didn't have that prob lol, it's not much in terms of good looks lol.
Clunky looking thing, no offence.

I wish it was programmed a bit diffrently and had a better interface.
I know that's not likely to happen though.

I can use everest's html/registry interface to get my readings in xp and win7's desktop (active desktop or gadget).
Prob is, in win7, the gadget interface takes up 50megs for no reason, and an extra process.
I don't use gadgets right now because of that.

That and everest needs to be running in the bg, which adds on to that.
Not worth using a 100megs for temp's and voltage readings.
:\

Well I got other uses for the active desktop stuff but win7's implimentation of it sucks.

One of those opt temps are the mem sticks heatsink temp, the one stick closest to the cpu.
Another is my pwm heatsink temp and the other my ambient temps.
I dn which one is which at the moment lmao...

Shame everest doesn't have a branch off program only for temps and voltages .
I'de be using that if they did.

I was hoping hwmonitor would update for the ch4 board, with corrected div/mul methods for reading the values on this board, plus the missing stuff.
But so far no go on that one.

I thaught about trying mbm5.
The isa bridge chip is support by that program.
Likely it would only find a few of the things though and not all of it.
But apperently I can't get it to run in win7.

Speedfan.
Well, I can't run that at all anymore.
I haven't been able to run that for I think 2 years now.
It crashes on the cpu usage % reading when it's starting up.

Speedfan and the asus probe software don't run on my system because of the tweaks I did.
Which is my fault...
But that's because of the way they were written, if they were written better then they would run...

If anyone knows of an alternative that shows as much as everest does, I'm willing to try that...

Edit:
Oh CnQ...
@mav2000
Possible that you may need to set the cpu and cpu-nb voltages to auto or offset mode.
CnQ seems to work with a directly set multiplier though, you don't need it set to auto, at least I don't.

Check with cpu-z to see the active pwr state mode (cpu speed).
Hwmonitor helps with it's vcore value and cpu watt usage (should go down to around 60w's on idle).
And tMonitor shows you when turbo mode kicks in and etc.
I use all 3 to see what is going on.

You need the latest amd cpu driver though for it to work 100%.
In win7, min performance lv I have set to 5% (pwr management, advanced).

In xp, well, I reccomend you have it set to always on.
Because when you make a special power config for it (reg or cmd line), it acts up when switching pwr states.
The performance is horrible I mean.

Asus's epu program will make that power profile for you in xp.
You don't need that program get it to work though, just the amd driver.

But it does help make you a power profile if you don't allready have one like it in xp.
Like I said though, I don't reccomend using it.

This is the cause for the performance prob in xp when you try to fully use all of your pwr states:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Throttle]

;"PerfCriticalTimeDelta"=dword:000493e0			;Default, (300000 Dec), 300ms
;"PerfDecreaseAbsoluteModifier"=dword:00000001		;Default, 1%
;"PerfDecreaseMinimumTime"=dword:000249f0		;Default, (150000 Dec), 150ms
;"PerfDecreasePercentModifier"=dword:0000001e		;Default, (30 Dec), 30%
;"PerfDecreaseTimeValue"=dword:00002710			;Default, (10000 Dec), 10ms
;"PerfDegradeThrottleMinCapacity"=dword:00000032	;Default, (50 Dec), 50%

;Disables Throttling A CPU Using Acpi
"PerfEnablePackageIdle"=dword:00000000			;Disabled
;"PerfEnablePackageIdle"=dword:00000001			;Enabled

;"PerfIncreaseAbsoluteModifier"=dword:00000001		;Default, 1%
;"PerfIncreaseMinimumTime"=dword:000249f0		;Default, (150000 Dec), 150ms
;"PerfIncreasePercentModifier"=dword:00000014		;Default, (20 Dec), 20%
;"PerfIncreaseTimeValue"=dword:00002710			;Default, (10000 Dec), 10ms
;"PerfMaxC3Frequency"=dword:00000032			;Default, (50 Dec), 50%
;"PerfTimeDelta"=dword:00000000				;?

Thing is there is allmost 0 info on these settings and trying to adjust without that info, well I've tried a few times.
Been able to force the max performance level but that's about it.
:\

Win7's config for this stuff is totally diff.
It's pretty much adjustable in the cpl and actually works good ^^.

[BeepBeep2]

Coz everest is ... ( fill in on the dotted line) There's no FSB on AMD, HT clocks only. Disable the Turbo and see what happens then (I never use that function)

I've got horrible HTT fluctuation on my M4A89TD Pro/USB3...

[NEOAethyr]

@ Everyone that has fsb/ht and other mhz type of fluctuations.

Try disabling turbo mode, and check again.
If it fixed the probs that you wanna post back about that.

If it doesn't, other things I can think of are:
Set multipliers to manual instead of having it/them on auto.
Set voltages to manual.
Disable CnQ.

Disable LLC, and spread spectrum settings.

Those are the only other things I can think of.
It's probably turbo mode though...


My rant below, if you can't read then don't lol :
What gets me is, I'm not sure that we have a real prob.
It could be possible when a program reads a value (voltage or mhz), that if the interval between reads is to quick, the result could be "undefined result" as they say.

The fsb/ht clocks might be baised off some pci reg, mem offset, or msr.
If that were the case then there could be up to say 3 bytes total for the value, one of those may even be a multiplier/dividor value that takes the main value and mutltiplies it by it's value.
Like by 01h which could be, 1mhz, or even 0.016mhz, whatever.
If anyone of those reads back incorrectly then the whole reading is offset by whatever amount.

Or...
It could be much simpler then this ^^.
This is what I bet is happening.

Everest for example, is reading the cpu multiplier, from msr or pci reg (note we have 6 cores... ^^).
And then it takes that known multiplier value and divides it down by the current cpu clock, getting the fsb/ht value.
Ie, 250x10 = 2500, 2500 / 10 = 250mhz fsb...

It's probably using a real time clock msr or apci timer to find the cpu clock to divide with.

Now, here's the issue, we got 6 cores.
It's possible that there's times that it gets the whole algo wrong because it's dividing by a cpu clock that is incorrect, ie turbo mode...

Lets see if I can think of some good examples.
200x10 normal mode, x11 = turbo.
Interval say is speced at 1000ms, but everest is reading it at 100ms (example only).

So...
2000 / 10 = 200
2200 / 11 = 200
2200 / 10 = 220
Everest knows the msr for the cpu mutli is 10x, but the cpu clock still hasn't died down to 2000mhz yet.
So the fsb result is 220mhz, which is incorrect ^^.

In this example it might happen 2 out of 10 times, each of the 2 times is diff.
Say one is like the above example, and the other could be 2000 / 11.

In real life I think it might be 1 out of 4 reading are incorrect, or 1 out of 8 (2 of 8 being incorrect in total possibly).

That is what I think is going on.
That and being that I have 6 cores, getting them all to divide correctly into the fsb using the real time cpu clocks and multipliers, well, it's no wonder this is happening.

At least I think...

This I think explains why most programs don't pick up on it, because there read interval is slow enough not to get messed up.

I believe the cpu pwr state switching interval is around 10ms (guessing).
I doubt you're supposed to read it that fast though.
And it's more then 1 reg that needs to be read out.
Plus the code that does all of this (everest for example), I think there's room in there for the error to happen and the reason why we see all of the clocks that are dependent on the cpu/fsb as varient all messed up sometimes.

To put it simply.
We might not have any prob at all.
The only real prob is the switching speeds and software reading speeds.

I'm gonna check xp/2k3 to see if I see the prob there.
Because thw switching speed in that os for pwr states is likely diffrent from win7, at least a little bit.

[Tonyb]

I only get fluctuations of 0.1Mhz on the bus and the HT with turbo enabled and disabled.

[NEOAethyr]

@Tonyb
Is this in win7, with everest?
No flututation?

I guess I'm gonna check one more thing, disable turbo and set a 15x normal multi, maybe it's just my own system pushing it to far.

Edit:
I was totally wrong.
Fluctuation only happens in turbo mode for me.
Regardless of how far I push my system, I tried setting a normal multi of 15x and disabling turbo mode.
What I got was 275x15, 4125mhz with 0 flutuation in the fsb and little in the ht and mem.

What is odd though, mem and ht speeds do fluctuate without the fsb fluctuating at all.
Though it was very min, 1mhz at best, most of the time it was 0.01mhz diff.
Which is pretty normal for any board really.

Now what in the world is wrong with my turbo mode...
Some people have probs some don't, diff board rev's or something?
And is it turbo mode in it's self to blame for everyone that has the probs?

Then why would turbo act diffrently on 1 board to the next...

I do know one thing, something that struck me as weird.
I was under the impression before I built this system that turbo mode only worked for 5 out of the 6 cores in total at any given time.
While mine can do all 6 cores at once, that's why I use it because it's just an extra power state (abiet config'ed slightly diff then the other pwr states perhaps).
I dn I just think that maybe turbo mode's slight diff in config in relation to the other pwr states is what is causing the prob.

I'm gonna have to work on not using turbo mode for a while and get my system up back to speed ^^.

Sorry if my posts seem like they are full of bs and randomess ^^.

[zoomee]

The HT fluctuations seem common to the asus boards.

I had the M4a89GTD/PRo-USB3 - At first it NEVER used to fluctuate the HT - upon installing the BIOS's from around April onwards they fluctuate roughly 1 - 2 Mhz - Now that may not seem much but times that by 20 and you can see how easily the CPU jumps around from 4013Mhz to 4045Mhz - thats make or break a 4ghz clock.

I decided to give the Crosshair IV a go - thinking that would be better but WAHAY! - That was even worse back in August - tried the standard bios (original one) and the latest one available from here - no joy - But aswell as HT fluctuating (more so than my M4A89) the voltage also used to fluctuate a heck of allot! - This was definately due to turbo - as soon as I switched that off the crosshair IV volts behaved themselves.

In terms of Trying LLC and other settings on manual - NONE of these make a difference. Asus really need to get they're act in gear and sort this out as it can render overclocks unstable with what seems such a minor HT fluctuation (when using high multipliers on CPU)

Anyway - it looks like my M4A89GTD has crapped out on me - Cap busted and in turn caused my PSU to overheat and burn out the connectors - nice one asus! - looks like i'll be seeking compensation from either the PSU manufacturer (XFX) or Asus. I've just bought the crosshair IV (again!) in the hope Asus will sort out they're bios - I've always been an MSI fan - but have given Asus another chance for now.........

Please don't let us down Asus - THIS IS A BIOS ISSUE common to ALL Asus boards- Please address asap -and also decrease boot time for these boards PLEASE!

[Tonyb]

Win 7 using Everest and CPU-Z. Have you tried disabling the Spread Spectrum? it works by modulating frequencies to cut down on EMI.
One method of minimizing the EMI that a device generates is to keep the disturbing signals below a certain level. You accomplish this goal by modulating the disturbing signals
across a wider frequency range, thus spreading the energy across a range of frequencies rather than concentrating it at one frequency. In PCIe systems, the modulation of the
reference clock is spread-spectrum clocking. The PCIe specification uses the down-spread approach when using a 30- to 33-kHz-wave signal as the modulating
frequency to the 100-MHz clock, resulting in a frequency range of 99.5 to 100 MHz.

[BeepBeep2]

@ Everyone that has fsb/ht and other mhz type of fluctuations.
1.
Try disabling turbo mode, and check again.
If it fixed the probs that you wanna post back about that.

2.
If it doesn't, other things I can think of are:
Set multipliers to manual instead of having it/them on auto.
Set voltages to manual.
Disable CnQ.

3.
Disable LLC, and spread spectrum settings.

4.
Those are the only other things I can think of.
It's probably turbo mode though...


My rant below, if you can't read then don't lol :
What gets me is, I'm not sure that we have a real prob.
It could be possible when a program reads a value (voltage or mhz), that if the interval between reads is to quick, the result could be "undefined result" as they say.

The fsb/ht clocks might be baised off some pci reg, mem offset, or msr.
If that were the case then there could be up to say 3 bytes total for the value, one of those may even be a multiplier/dividor value that takes the main value and mutltiplies it by it's value.
Like by 01h which could be, 1mhz, or even 0.016mhz, whatever.
If anyone of those reads back incorrectly then the whole reading is offset by whatever amount.

Or...
It could be much simpler then this ^^.
This is what I bet is happening.

Everest for example, is reading the cpu multiplier, from msr or pci reg (note we have 6 cores... ^^).
And then it takes that known multiplier value and divides it down by the current cpu clock, getting the fsb/ht value.
Ie, 250x10 = 2500, 2500 / 10 = 250mhz fsb...

It's probably using a real time clock msr or apci timer to find the cpu clock to divide with.

Now, here's the issue, we got 6 cores.
It's possible that there's times that it gets the whole algo wrong because it's dividing by a cpu clock that is incorrect, ie turbo mode...

Lets see if I can think of some good examples.
200x10 normal mode, x11 = turbo.
Interval say is speced at 1000ms, but everest is reading it at 100ms (example only).

So...
2000 / 10 = 200
2200 / 11 = 200
2200 / 10 = 220
Everest knows the msr for the cpu mutli is 10x, but the cpu clock still hasn't died down to 2000mhz yet.
So the fsb result is 220mhz, which is incorrect ^^.

In this example it might happen 2 out of 10 times, each of the 2 times is diff.
Say one is like the above example, and the other could be 2000 / 11.

In real life I think it might be 1 out of 4 reading are incorrect, or 1 out of 8 (2 of 8 being incorrect in total possibly).

That is what I think is going on.
That and being that I have 6 cores, getting them all to divide correctly into the fsb using the real time cpu clocks and multipliers, well, it's no wonder this is happening.

At least I think...

This I think explains why most programs don't pick up on it, because there read interval is slow enough not to get messed up.

I believe the cpu pwr state switching interval is around 10ms (guessing).
I doubt you're supposed to read it that fast though.
And it's more then 1 reg that needs to be read out.
Plus the code that does all of this (everest for example), I think there's room in there for the error to happen and the reason why we see all of the clocks that are dependent on the cpu/fsb as varient all messed up sometimes.

To put it simply.
We might not have any prob at all.
The only real prob is the switching speeds and software reading speeds.

I'm gonna check xp/2k3 to see if I see the prob there.
Because thw switching speed in that os for pwr states is likely diffrent from win7, at least a little bit.

1. I have a 965BE, it's automatically off.

2. I do all of that, as I am an overclocker and don't like C&Q much as well.

3. LLC is ENABLED, as vdroop is horrible on this board. Spread Spectrum is disabled.

4. It's not turbo mode

As for the rant about programs reading too slow and not seeing it, CPU-Z's polling rate is roughly 2500ms. It sees it, as well as AMD overdrive which is more around 200ms.

OK, i'm taking what i said back. Had a flat battery in my DMM and relied on Asus PC Probe for the voltages readings. I knew i should not trust a soft but the fact that it showed the 12v, 5v and 3.3v rock solid made me wonder why voltage swing would only affect the other voltages, why would PC Probe not affect those three too.
Well, i changed DMM's battery and took readings and there is no voltage swing other than .01v here and there and i suspect that's when the voltage is standing near .xx9 or .xx0
So, to summarize, PC Probe is putting as much as .04v swing where there is almost none

I suspected this all along, CPUZ only reports in .012v swings, and every time it goes from 1.512v to 1.524v or 1.536v people tend to freak out about it. Basically if the voltage is moving from 1.517v to 1.519v it's going to read a .012v change when it's really .002v.

[LowRun]

I suspected this all along, CPUZ only reports in .012v swings, and every time it goes from 1.512v to 1.524v or 1.536v people tend to freak out about it. Basically if the voltage is moving from 1.517v to 1.519v it's going to read a .012v change when it's really .002v.

Seriously their software is not making their hardware look good

[BeepBeep2]

Seriously their software is not making their hardware look good

It's a limitation of all voltage reading software. HWMonitor, CPU-Z, etc all do the same thing.

[LowRun]

It's a limitation of all voltage reading software. HWMonitor, CPU-Z, etc all do the same thing.

Of course it's a software limitation, been known for ages, what i'm getting at is that PC Probe is even more inaccurate (way more i should add) despite the fact that it is an Asus software.