Originally Posted by
NEOAethyr
@ 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.
