MMM
Results 1 to 25 of 1343

Thread: ASUS AMD Beta BIOS Releases

Threaded View

  1. #10
    Xtreme 3D Team
    Join Date
    Jan 2009
    Location
    Ohio
    Posts
    8,499
    Quote Originally Posted by NEOAethyr View Post
    @ 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.

    Quote Originally Posted by LowRun View Post
    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.
    Last edited by BeepBeep2; 10-23-2010 at 11:35 AM.
    Smile

Tags for this Thread

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •